C#三層架構(gòu)詳解

1、 三層架構(gòu)將數(shù)據(jù)層、應用層和業(yè)務層分離，業(yè)務層通過應用層訪問數(shù)據(jù)庫，保護數(shù)據(jù)安 全，利于負載平衡，提高運行效率，方便構(gòu)建不同網(wǎng)絡(luò)環(huán)境下的分布式應用； 業(yè)務層主要作用是接收用戶的指令或者數(shù)據(jù)輸入，提交給應用層做處理，同時負責將 業(yè)務邏輯層的處理結(jié)果顯示給用戶。相比傳統(tǒng)的應用方式，業(yè)務層對硬件的資源要求較 低； 應用層依據(jù)應用規(guī)模的不同，所承受的負荷會有較大的差異，另外客戶端的數(shù)目，應 用的復雜程度都會對其造成一定的影響。 ERP三層結(jié)構(gòu)提供了非常好的可擴張性，可以將邏輯服務分布到多臺服務器來處理，從 而提供了良好的伸縮方案； 數(shù)據(jù)層包括存儲數(shù)據(jù)的數(shù)據(jù)庫服務器和處理數(shù)據(jù)和緩存數(shù)據(jù)的組件。組件將大量

2、使用 的數(shù)據(jù)放入系統(tǒng)的緩存庫，以提高數(shù)據(jù)訪問和處理的效率 同時ERP用大型數(shù)據(jù)庫提供高性能、可靠性高的海量數(shù)據(jù)存儲能力存儲 ERP的業(yè)務數(shù) 據(jù)。 三層架構(gòu)(3-tier application)通常意義上的三層架構(gòu)就是將整個業(yè)務應用劃分為： 表現(xiàn)層 (UI)、業(yè)務邏輯層(BLD、數(shù)據(jù)訪問層(DAL)。區(qū)分層次的目的即為了 “高內(nèi)聚， 低耦合”的思想。 概念簡介 1、 表現(xiàn)層 （UI）:通俗講就是展現(xiàn)給用戶的界面，即用戶在使用一個系統(tǒng) 的時候他的所見所得。 2、 業(yè)務邏輯層（BLL）:針對具體問題的操作，也可以說是對數(shù)據(jù)層的操 作，對數(shù)據(jù)業(yè)務邏輯處理。 3、 數(shù)據(jù)訪問層（DAL）:該層所做事務直

3、接操作數(shù)據(jù)庫，針對數(shù)據(jù)的增添、 刪除、修改、更新、查找等。 概述 在軟件體系架構(gòu)設(shè)計中，分層式結(jié)構(gòu)是最常見，也是最重要的一種結(jié)構(gòu)。微 軟推薦的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務邏輯層 （又或成為領(lǐng)域?qū)樱⒈硎緦印?三層結(jié)構(gòu)原理： 3個層次中，系統(tǒng)主要功能和業(yè)務邏輯都在業(yè)務邏輯層進行處理。 所謂三層體系結(jié)構(gòu)， 是在客戶端與數(shù)據(jù)庫之間加入了一個 中間層”，也叫組件 層。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是 三層體系結(jié)構(gòu)， 也不僅僅有 B/S應用才是三層體系結(jié)構(gòu)， 三層是指邏輯上的三層， 即使這三個層放置到一臺機器上。 三層體系的應用程序?qū)I(yè)務規(guī)則

4、、數(shù)據(jù)訪問、合法性校驗等工作放到了中間 層進行處理。通常情況下，客戶端不直接與數(shù)據(jù)庫進行交互，而是通過 COM/DC OM通訊與中間層建立連接，再經(jīng)由中間層與數(shù)據(jù)庫進行交互。 表小層 位于最外層（最上層），離用戶最近。用于顯示數(shù)據(jù)和接收用戶輸入的數(shù) 據(jù)，為用戶提供一種交互式操作的界面 業(yè)務邏輯層 業(yè)務邏輯層(Business Logic Layer )無疑是系統(tǒng)架構(gòu)中體現(xiàn)核心價值的 部分。它的關(guān)注點主要集中在業(yè)務規(guī)則的制定、業(yè)務流程的實現(xiàn)等與業(yè)務需求有 關(guān)的系統(tǒng)設(shè)計，也即是說它是與系統(tǒng)所應對的領(lǐng)域( Domain )邏輯有關(guān)，很多時 候，也將業(yè)務邏輯層稱為領(lǐng)域?qū)?。例?Martin Fowle

5、r在Patterns of Enterpri se Application Architecture 一書中，將整個架構(gòu)分為三個主要的層：表示層、 領(lǐng)域?qū)雍蛿?shù)據(jù)源層。作為領(lǐng)域驅(qū)動設(shè)計的先驅(qū) Eric Evans ,對業(yè)務邏輯層作了更 細致地劃分，細分為應用層與領(lǐng)域?qū)?，通過分層進一步將領(lǐng)域邏輯與領(lǐng)域邏輯的 解決方案分離。 業(yè)務邏輯層在體系架構(gòu)中的位置很關(guān)鍵，它處于數(shù)據(jù)訪問層與表示層中間， 起到了數(shù)據(jù)交換中承上啟下的作用。由于層是一種弱耦合結(jié)構(gòu)，層與層之間的依 賴是向下的，底層對于上層而言是 無知”的，改變上層的設(shè)計對于其調(diào)用的底層而 言沒有任何影響。如果在分層設(shè)計時，遵循了面向接口設(shè)計的思想，那

6、么這種向 下的依賴也應該是一種弱依賴關(guān)系。因而在不改變接口定義的前提下，理想的分 層式架構(gòu)，應該是一個支持可抽取、可替換的 抽屜”式架構(gòu)。正因為如此，業(yè)務邏 輯層的設(shè)計對于一個支持可擴展的架構(gòu)尤為關(guān)鍵， 因為它扮演了兩個不同的角色。 對于數(shù)據(jù)訪問層而言，它是調(diào)用者；對于表示層而言，它卻是被調(diào)用者。依賴與 被依賴的關(guān)系都糾結(jié)在業(yè)務邏輯層上，如何實現(xiàn)依賴關(guān)系的解耦，則是除了實現(xiàn) 業(yè)務邏輯之外留給設(shè)計師的任務。 數(shù)據(jù)層 數(shù)據(jù)訪問層：有時候也稱為是持久層，其功能主要是負責數(shù)據(jù)庫的訪問， 可以訪問數(shù)據(jù)庫系統(tǒng)、二進制文件、文本文檔或是 XML文檔。 簡單的說法就是實現(xiàn)對數(shù)據(jù)表的 Select , Inse

7、rt , Update , Delete的操作。 如果要加入 ORM的元素，那么就會包括對象和數(shù)據(jù)表之間的 mapping ,以及對 象實體的持久化。 優(yōu)缺點 優(yōu)點 1、 開發(fā)人員可以只關(guān)注整個結(jié)構(gòu)中的其中某一層； 2、 可以很容易的用新的實現(xiàn)來替換原有層次的實現(xiàn)； 3、可以降低層與層之間的依賴; 4、 有利于標準化； 5、 利于各層邏輯的復用。 缺點 1、 降低了系統(tǒng)的性能。這是不言而喻的。如果不采用分層式結(jié)構(gòu)，很多業(yè)務 可以直接造訪數(shù)據(jù)庫，以此獲取相應的數(shù)據(jù)，如今卻必須通過中間層來完成。 2、 有時會導致級聯(lián)的修改。這種修改尤其體現(xiàn)在自上而下的方向。如果在表 示層中需要增加一個功能，為保證

8、其設(shè)計符合分層式結(jié)構(gòu)，可能需要在相應的業(yè) 務邏輯層和數(shù)據(jù)訪問層中都增加相應的代碼。 規(guī)則 三層結(jié)構(gòu)的程序不是說把項目分成 DAL, BLL, WebUI三個模塊就叫三層了 ， 下面幾個問題在你的項目里面： 1. UILayer里面只有少量(或者沒有)的SQL語句或者存儲過程調(diào)用，并且這 些語句保證不會修改數(shù)據(jù) ？ 2. 如果把UILayer拿掉,你的項目還能在 Interface/API的層次上提供所有功 能嗎？ 3. 你的DAL可以移植到其他類似環(huán)境的項目嗎 ？ 4. 三個模塊,可以分別運行于不同的服務器嗎 ？ 如果不是所有答案都為 YES,那么你的項目還不能算是嚴格意義上的三層程 序.三層

9、程序有一些需要約定遵守的規(guī)則： 1. 最關(guān)鍵的，UI層只能作為一個外殼 ，不能包含任何 BizLogic的處理過程 2. 設(shè)計時應該從 BLL出發(fā)，而不是UI出發(fā).BLL層在API上應該實現(xiàn)所有 B izLogic, 以面向?qū)ο蟮姆绞?3. 不管數(shù)據(jù)層是一個簡單的 SqlHelper也好，還是帶有Mapping過的Class es也好，應該在一定的抽象程度上做到系統(tǒng)無關(guān) 4. 不管使用 COM+(Enterprise Service),還是 Remoting,還是 WebService 之類的遠程對象技術(shù)，不管部署的時候是不是真的分別部署到不同的服務器上 ， 最起碼在設(shè)計的時候要做這樣的考慮

10、，更遠的，還得考慮多臺服務器通過負載均 衡作集群 所以考慮一個項目是不是應該應用三層 /多層設(shè)計時，先得考慮下是不是真的 需要？實際上大部分程序就開個 WebApplication 就足夠了 ,完全沒必要作的這么 復雜.而多層結(jié)構(gòu)，是用于解決真正復雜的項目需求的。 與MVC的區(qū)別 MVC （模型 Model-視圖View-控制器Controller ）是一種設(shè)計模式，我們可 以用它來創(chuàng)建在域?qū)ο蠛?UI表示層對象之間的區(qū)分。 同樣是架構(gòu)級別的，相同的地方在于他們都有一個表現(xiàn)層，但是他們不同的 地方在于其他的兩個層。 在三層架構(gòu)中沒有定義 Controller的概念。這是我認為最不同的地方。 而

11、MVC 也沒有把業(yè)務的邏輯訪問看成兩個層， 這是采用三層架構(gòu)或 MVC搭建程序最主要 的區(qū)別。當然了。在三層中也提到了 Model ,但是三層架構(gòu)中 Model的概念與 MVC中Model的概念是不一樣的， 蘭層”中典型的 Model層是以實體類構(gòu)成的， 而MVC里，則是由業(yè)務邏輯與訪問數(shù)據(jù)組成的。 三層結(jié)構(gòu)的優(yōu)點 分層式結(jié)構(gòu)究竟其優(yōu)勢何在？ Martin Fowler 在Patterns of Enterprise Application Architecture 一書中給出了答案： 1、 開發(fā)人員可以只關(guān)注整個結(jié)構(gòu)中的其中某一層； 2、 可以很容易的用新的實現(xiàn)來替換原有層次的實現(xiàn)； 3、

12、可以降低層與層之間的依賴； 4、 有利于標準化； 5、 利于各層邏輯的復用。 概括來說，分層式設(shè)計可以達至如下目的：分散關(guān)注、松散耦合、邏輯復用、標準 定義。 一個好的分層式結(jié)構(gòu)， 可以使得開發(fā)人員的分工更加明確。 一旦定義好各層次之間 的接口，負責不同邏輯設(shè)計的開發(fā)人員就可以分散關(guān)注，齊頭并進。例如 UI人員只需 考慮用戶界面的體驗與操作， 領(lǐng)域的設(shè)計人員可以僅關(guān)注業(yè)務邏輯的設(shè)計， 而數(shù)據(jù)庫設(shè) 計人員也不必為繁瑣的用戶交互而頭疼了。每個開發(fā)人員的任務得到了確認，開發(fā)進度 就可以迅速的提高。 松散耦合的好處是顯而易見的。 如果一個系統(tǒng)沒有分層， 那么各自的邏輯都緊緊糾 纏在一起，彼此間相互依賴

13、，誰都是不可替換的。一旦發(fā)生改變，則牽一發(fā)而動全身， 對項目的影響極為嚴重。降低層與層間的依賴性，既可以良好地保證未來的可擴展，在 復用性上也是優(yōu)勢明顯。每個功能模塊一旦定義好統(tǒng)一的接口， 就可以被各個模塊所調(diào) 用，而不用為相同的功能進行重復地開發(fā)。 進行好的分層式結(jié)構(gòu)設(shè)計，標準也是必不可少的。只有在一定程度的標準化基礎(chǔ)上， 這個系統(tǒng)才是可擴展的，可替換的。而層與層之間的通信也必然保證了接口的標準化。 如果是一個考試系統(tǒng)， 考試合格的最低分數(shù)線要改， 只需要修改業(yè)務邏輯相對應函 數(shù)就可以了，只要此函數(shù)的入口參數(shù)和返回內(nèi)容不變，在客戶端不需作任何改動。在這 里，看到了面向?qū)ο缶幊痰奶匦灾环庋b性

14、的優(yōu)點，而這一點在開發(fā)大型應用時尤其有 用，可以把開發(fā)人員分成兩組，一組負責開發(fā)界面層，另一組負責開發(fā)商業(yè)邏輯層，雙 方只要按照事先商定的函數(shù)接口，并行地開發(fā)就可以，而不必向從前那樣，后面的工作 必須等前面的工作完成后才能開始。當然，這樣的開發(fā)模式需要很好的項目協(xié)調(diào)和文檔 作支持。 如果現(xiàn)在用的系統(tǒng)是 SQL SERVE散據(jù)庫，由于各種原因要更改用 ORACLE如果不 是三層結(jié)構(gòu)系統(tǒng)的話，可能需要改很多代碼，延長了開發(fā)周期?，F(xiàn)在使用了三層結(jié)構(gòu)， 只要在加一個Oracle的數(shù)據(jù)訪問層。這樣就可以實現(xiàn)多數(shù)據(jù)庫了。 現(xiàn)在可能要做另外一個系統(tǒng)了，該系統(tǒng)也要對數(shù)據(jù)庫進行操作。如果以前編寫過， 這樣的一個

15、數(shù)據(jù)層。只要把以前寫的那個數(shù)據(jù)層拷貝過來就可以了。實現(xiàn)代碼復用。從 而減短了軟件的開發(fā)周期了。 三層結(jié)構(gòu)的缺點 “金無足赤，人無完人”，分層式結(jié)構(gòu)也不可避免具有一些缺陷： 1、 降低了系統(tǒng)的性能。這是不言而喻的。如果不采用分層式結(jié)構(gòu)，很多業(yè)務可以 直接造訪數(shù)據(jù)庫，以此獲取相應的數(shù)據(jù)，如今卻必須通過中間層來完成。 2、 有時會導致級聯(lián)的修改。這種修改尤其體現(xiàn)在自上而下的方向。如果在表示層 中需要增加一個功能，為保證其設(shè)計符合分層式結(jié)構(gòu)，可能需要在相應的業(yè)務邏輯層和 數(shù)據(jù)訪問層中都增加相應的代碼。 基于組件的三層B/S結(jié)構(gòu)概述 在軟件體系架構(gòu)設(shè)計中，分層式結(jié)構(gòu)是最常見，也是最重要的一種結(jié)構(gòu)。微軟推

16、薦 的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務邏輯層（又或成為領(lǐng) 域?qū)樱?、表示層?三層結(jié)構(gòu)原理 3個層次中，系統(tǒng)主要功能和業(yè)務邏輯都在業(yè)務邏輯層進行處理 所謂三層體系結(jié)構(gòu)，是在客戶端與數(shù)據(jù)庫之間加入了一個“中間層”，也叫組件層。 這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結(jié) 構(gòu)，也不僅僅有B/S應用才是三層體系結(jié)構(gòu)，三層是指邏輯上的三層，即使這三個層放 置到一臺機器上。 三層體系的應用程序?qū)I(yè)務規(guī)則、 數(shù)據(jù)訪問、合法性校驗等工作放到了中間層進行 處理。通常情況下，客戶端不直接與數(shù)據(jù)庫進行交互，而是通過 COM/DCOM通訊與中 間層建立連接，再

17、經(jīng)由中間層與數(shù)據(jù)庫進行交互。 表示層 位于最外層（最上層），離用戶最近。用于顯示數(shù)據(jù)和接收用戶輸入的數(shù)據(jù)，為用 戶提供一種交互式操作的界面 業(yè)務邏輯層 業(yè)務邏輯層（Business Logic Layer無疑是系統(tǒng)架構(gòu)中體現(xiàn)核心價值的部分。它的 關(guān)注點主要集中在業(yè)務規(guī)則的制定、業(yè)務流程的實現(xiàn)等與業(yè)務需求有關(guān)的系統(tǒng)設(shè)計，也 即是說它是與系統(tǒng)所應對的領(lǐng)域（Domain）邏輯有關(guān)，很多時候，也將業(yè)務邏輯層稱為 領(lǐng)域?qū)?。例?Martin Fowler 在Patterns of Enterprise Application Architecture一書中， 將整個架構(gòu)分為三個主要的層：表示層、領(lǐng)域?qū)雍?/p>

18、數(shù)據(jù)源層。作為領(lǐng)域驅(qū)動設(shè)計的先驅(qū) Eric Evans對業(yè)務邏輯層作了更細致地劃分，細分為應用層與領(lǐng)域?qū)?，通過分層進一步 將領(lǐng)域邏輯與領(lǐng)域邏輯的解決方案分離。 業(yè)務邏輯層在體系架構(gòu)中的位置很關(guān)鍵， 它處于數(shù)據(jù)訪問層與表示層中間， 起到了 數(shù)據(jù)交換中承上啟下的作用。由于層是一種弱耦合結(jié)構(gòu)，層與層之間的依賴是向下的， 底層對于上層而言是“無知”的，改變上層的設(shè)計對于其調(diào)用的底層而言沒有任何影響。 如果在分層設(shè)計時，遵循了面向接口設(shè)計的思想，那么這種向下的依賴也應該是一種弱 依賴關(guān)系。因而在不改變接口定義的前提下，理想的分層式架構(gòu)，應該是一個支持可抽 取、可替換的“抽屜”式架構(gòu)。正因為如此，業(yè)務邏輯

19、層的設(shè)計對于一個支持可擴展的 架構(gòu)尤為關(guān)鍵，因為它扮演了兩個不同的角色。對于數(shù)據(jù)訪問層而言，它是調(diào)用者；對 于表示層而言，它卻是被調(diào)用者。依賴與被依賴的關(guān)系都糾結(jié)在業(yè)務邏輯層上，如何實 現(xiàn)依賴關(guān)系的解耦，則是除了實現(xiàn)業(yè)務邏輯之外留給設(shè)計師的任務。 數(shù)據(jù)層 數(shù)據(jù)訪問層：有時候也稱為是持久層，其功能主要是負責數(shù)據(jù)庫的訪問，可以訪問 數(shù)據(jù)庫系統(tǒng)、二進制文件、文本文檔或是 XML文檔。 簡單的說法就是實現(xiàn)對數(shù)據(jù)表的 Select, Insert, Update, Delete的操作。如果要加 入ORM的元素，那么就會包括對象和數(shù)據(jù)表之間的 mapping ,以及對象實體的持久化。 MVC與三層架構(gòu)的異

20、同點 同樣是架構(gòu)級別的，它們有什么相同點和不同點呢？這篇文章討論一下它們的異同 點。希望能幫助讀者理解其中的玄機。 ：） 其實它們相同的地方在于他們都有一個表現(xiàn)層。 但是他們不同的地方在于其他的兩個層。 首先先解釋一下 MVC。V即View.是視圖的意思。C即Controler.是控制器的意思 而M即Model，是模型的意思。這三個里.最不容易理解的應該是 Model.就是什么是 Model，而為什么叫 Model。我先不說為什么叫 Model，先解釋 Controler。 Controller是控制器的意思，所謂控制器，就是將用戶請求轉(zhuǎn)發(fā)給模型層，經(jīng)過處 理后把結(jié)果返回到界面展現(xiàn)的一個中間層，那么 Controler到底管什么工作呢？先不說. 先來看下在Java Web中這三個層一般的定義，一般