三層架構利弊及用法

名詞解釋

架構：架構通常是針對整個系統的，並不是針對某個單獨的問題（單獨問題能夠用模式等來解決）針對整個系統的」一個藍圖」，對系統的抽象。

模式：軟件開發中遇到的一些特定問題，前人總結出來特定的經驗、解決方法。

框架：架構設計、模式應用的經驗積累的具體代碼實現，方便之後的複用。

三層

表現層UI（User Interface）：通俗講就是展示給用戶的界面，即用戶在使用一個系統的時候他的所見所得。

業務邏輯層BLL（Business Logic Layer）：針對具體問題的操做，也能夠說是對數據層的操做，對數據業務邏輯處理。（備註：又稱領域層，經常使用於業務規則、數據訪問、合法性校驗）

數據訪問層DAL（Data Access Layer）：針對具體問題的操做，也能夠說是對數據層的操做，對數據業務邏輯處理。（領域對象：crud）

（新的：邏輯層就像房屋中介，租房買房更快捷了，但消耗的錢也更多了。）

優勢：

一、開發人員能夠只關注整個結構中的其中某一層；

二、能夠很容易的用新的實現來替換原有層次的實現；

三、能夠下降層與層之間的依賴；

四、有利於標準化；

五、利於各層邏輯的複用。

六、結構更加的明確

七、在後期維護的時候，極大地下降了維護成本和維護時間

缺點：

一、下降了系統的性能。這是不言而喻的。若是不採用分層式結構，不少業務能夠直接造訪數據庫，以此獲取相應的數據，現在卻必須經過中間層來完成。

二、有時會致使級聯的修改。這種修改尤爲體如今自上而下的方向。若是在表示層中須要增長一個功能，爲保證其設計符合分層式結構，可能須要在相應的業務邏輯層和數據訪問層中都增長相應的代碼。

三、增長了開發成本。

規則：

三層結構的程序不是說把項目分紅DAL,BLL,WebUI三個模塊就叫三層了，下面幾個問題在你的項目裏面：

⒈ UILayer裏面只有少許（或者沒有）SQL語句或者存儲過程調用，而且這些語句保證不會修改數據?

⒉ 若是把UILayer拿掉，你的項目還能在Interface/API的層次上提供全部功能嗎?

⒊ 你的DAL能夠移植到其餘相似環境的項目嗎?

⒋ 三個模塊，能夠分別運行於不一樣的服務器嗎?

若是不是全部答案都爲YES，那麼你的項目還不能算是嚴格意義上的三層程序. 三層程序有一些須要約定遵照的規則：

⒈ 最關鍵的，UI層只能做爲一個外殼，不能包含任何BizLogic的處理過程

⒉ 設計時應該從BLL出發，而不是UI出發. BLL層在API上應該實現全部BizLogic，以面向對象的方式

⒊ 無論數據層是一個簡單的SqlHelper也好，仍是帶有Mapping過的Classes也好，應該在必定的抽象程度上作到系統無關

⒋ 無論使用COM+(Enterprise Service），仍是Remoting，仍是WebService之類的遠程對象技術，無論部署的時候是否是真的分別部署到不一樣的服務器上，最起碼在設計的時候要作這樣的考慮，更遠的，還得考慮多臺服務器經過負載均衡做集羣

因此考慮一個項目是否是應該應用三層/多層設計時，先得考慮下是否是真的須要? 實際上大部分程序就開個WebApplication就足夠了，徹底不必做的這麼複雜. 而多層結構，是用於解決真正複雜的項目需求的。

三層結構示圖

 

 

三層與MVC的區別

一樣是架構級別的，它們有什麼相同點和不一樣點呢？這篇文章討論一下它們的異同點。但願能幫助讀者理解其中的玄機。

其實它們相同的地方在於他們都有一個表現層。

可是他們不一樣的地方在於其餘的兩個層。

首先先解釋一下MVC。V即View.是視圖的意思。C即Controler.是控制器的意思。而M即Model，是模型的意思。這三個裏.最不容易理解的應該是Model.就是什麼是Model，而爲何叫Model。我先不說爲何叫Model，先解釋Controler。

Controller是控制器的意思，所謂控制器，就是將用戶請求轉發給模型層，通過處理後把結果返回到界面展示的一箇中間層，那麼Controler到底管什麼工做呢？先不說.先來看下在Java Web中這三個層通常的定義，通常在Java Web裏，JSP充當V，Servlet充當C,JavaBean充當M，這裏的Servlet管什麼工做呢？接受輸入，轉到Model層去處理，處理結果保存後轉發到JSP，而後展示數據。因此它的功能就是控制器的基本功能，它就管轉發，在V和M之間轉來轉去。

再來講說M，即Model，在Java Web裏說的是JavaBean，我認識的不少人都把JavaBean誤認爲是實體類，其實JavaBean有比實體類更豐富的定義，在JavaBean中除了其屬性和字段，還能夠有行爲及其事件，JavaBean能夠理解爲普通Java對象。Java普通對象，就是符合Java規範的全部對象，這和實體類徹底是兩回事。因此，我認爲在MVC中。業務邏輯和數據訪問應該放在Model層，也就是V負責展現數據，Controler除了轉發不作業務邏輯。真正的邏輯事務，數據訪問，甚至算法都放到Model去。

再說三層架構。三層其實很好理解，界面，業務，數據訪問，就這三個，從字面均可以理解出它們的意思。我要說的是它和MVC的區別。在三層架構中沒有定義Controler的概念。這是我認爲最不一樣的地方。而MVC也沒有把業務的邏輯訪問當作兩個層，這是採用三層架構或MVC搭建程序最主要的區別。

固然了。在三層中也提到了Model，可是三層架構中Model的概念與MVC中Model的概念是不同的，「三層」中典型的Model層是已實體類構成的，而MVC裏，則是由業務邏輯與訪問數據組成的。不同的概念。雖然名字同樣。

SqlHelper類

SqlHelper.cs是多年前微軟出品的一個使用ADO.Net方法對SQL Server數據庫進行操做的封裝類。而咱們本身手寫的SqlHelper類一樣是對數據庫訪問方法的一個封裝類庫，讓咱們在訪問數據庫的時候能夠很方便地調用其中封裝的方法，省略了不少重複勞動。在聲明SqlHelper的時候,咱們通常會聲明爲一個靜態類，不使用靜態類的話有可能產生一些未知的錯誤（蘇老師說微軟說的）。

這個類中咱們經常使用的方法以下：

1. ExecuteNonQuery(): 執行簡單的無返回值的查詢。
2. ExecuteReader(): 使用DataReader讀取數據。（注：少許數據的狀況下使用   SqlDataReader的效率高於使用Dataset）
3. ExecuteScalar(): 返回結果集中的第一行第一列，至關於返回單個值。
4. ExcuteDataSet (): 返回Dataset的查詢，至關於返回一個數組。

除此以外，咱們根據須要以及興趣也能夠再增長一些其餘的方法，對其進行修改以及擴展。

三層使用及案例

第一部分：

登錄：對T_Seats表的查詢操做

修改密碼：對T_Seats表的修改操做

第二部分：

對T_Area表的刪除操做（主要知道遞歸刪除算法）

第三部分：

註冊（須要注意地方：一、添加操做須要output inserted.cc_AutoId 二、添加以前，還須要驗證當前用戶是否已經存在，用到了exists()作判斷）

第四部分：

建多個類庫，實現對T_Seats表和TblPerson表的操做，實現CRUD

 

 

---

1. Sql語句：select cc_autoId,cc_loginpassword,cc_userName from T_Seats where
2. 編寫數據訪問層（返回值是一個Model，參數是loginId）
   1. 寫model的時候寫徹底（也就是全部T_Seats中的列名都寫成屬性的形式）
   2. T_Seats model=null;
   3. return model;
   4. 因爲在讀取數據庫中是數據的時候，裏面只可以讀取到一條用戶名的信息，因此用if（reader.Read()）
3. 編寫業務邏輯層
   1. 首先須要查詢，就用到了數據訪問層中的信息，須要先實例化一個數據訪問層「類」
   2. CommonHelper中使用static（靜態類）
4. 表現層須要作的事情
   1. 採集數據：界面框中的數據
   2. 而後調用業務邏輯層
   3. 獲得業務邏輯層的返回值信息
   4. 由業務邏輯層的信息進行相應的操做（9:26兩out參數（why?））
   5. 表現層中寫GlobalHelper中的autoId的做用

---

修改密碼：（思路）

1.校驗兩次數據密碼是否一致（不須要sql語句）

2.校驗舊密碼是否正確（根據autoId來判斷舊密碼是否正確）

 

3.修改密碼（若是舊密碼正確的話，再開始進行    修改密碼    操做）

 

在BLL中的操做

1. 首先判斷返回給UI層的結果：用枚舉類型來寫
2. 獲得了返回值類型
3. 編寫修改密碼的方法，肯定參數

---

1. 省市加載到treeview上
2. 三層刪除當前節點下的全部節點（1在BLL層先寫一個刪除方法；2而後使用遞歸刪除方法；3在遞歸刪除過程中，又調用了加載過程中的遞歸加載方法）

---

項目的操做

分多個項目的增刪改查

配置文件放在UI層（表現層）

裏面的都寫成類庫類型

model中最好和表中的列同樣

多個項目之間須要在」引用「當中添加引用