解讀三層架構(gòu)技術(shù)

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

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

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

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

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

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

7、體的持久化。 優(yōu)缺點優(yōu)點1、開發(fā)人員可以只關(guān)注整個結(jié)構(gòu)中的其中某一層； 2、可以很容易的用新的實現(xiàn)來替換原有層次的實現(xiàn)； 3、可以降低層與層之間的依賴； 4、有利于標(biāo)準(zhǔn)化； 5、利于各層邏輯的復(fù)用。 缺點1、降低了系統(tǒng)的性能。這是不言而喻的。如果不采用分層式結(jié)構(gòu)，很多業(yè)務(wù)可以直接造訪數(shù)據(jù)庫，以此獲取相應(yīng)的數(shù)據(jù)，如今卻必須通過中間層來完成。 2、有時會導(dǎo)致級聯(lián)的修改。這種修改尤其體現(xiàn)在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設(shè)計符合分層式結(jié)構(gòu)，可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層中都增加相應(yīng)的代碼。 規(guī)則三層結(jié)構(gòu)的程序不是說把項目分成DAL, BLL, WebUI三個模塊就叫三

8、層了, 下面幾個問題在你的項目里面： 1. UILayer里面只有少量(或者沒有)的SQL語句或者存儲過程調(diào)用, 并且這些語句保證不會修改數(shù)據(jù)? 2. 如果把UILayer拿掉, 你的項目還能在Interface/API的層次上提供所有功能嗎? 3. 你的DAL可以移植到其他類似環(huán)境的項目嗎? 4. 三個模塊, 可以分別運行于不同的服務(wù)器嗎? 如果不是所有答案都為YES, 那么你的項目還不能算是嚴(yán)格意義上的三層程序. 三層程序有一些需要約定遵守的規(guī)則： 1. 最關(guān)鍵的, UI層只能作為一個外殼, 不能包含任何BizLogic的處理過程 2. 設(shè)計時應(yīng)該從BLL出發(fā), 而不是UI出發(fā). BLL層

9、在API上應(yīng)該實現(xiàn)所有BizLogic, 以面向?qū)ο蟮姆绞?3. 不管數(shù)據(jù)層是一個簡單的SqlHelper也好, 還是帶有Mapping過的Classes也好, 應(yīng)該在一定的抽象程度上做到系統(tǒng)無關(guān) 4. 不管使用COM+(Enterprise Service), 還是Remoting, 還是WebService之類的遠(yuǎn)程對象技術(shù), 不管部署的時候是不是真的分別部署到不同的服務(wù)器上, 最起碼在設(shè)計的時候要做這樣的考慮, 更遠(yuǎn)的, 還得考慮多臺服務(wù)器通過負(fù)載均衡作集群 所以考慮一個項目是不是應(yīng)該應(yīng)用三層/多層設(shè)計時, 先得考慮下是不是真的需要? 實際上大部分程序就開個WebApplication就

10、足夠了, 完全沒必要作的這么復(fù)雜. 而多層結(jié)構(gòu), 是用于解決真正復(fù)雜的項目需求的。與MVC的區(qū)別MVC（模型Model-視圖View-控制器Controller）是一種設(shè)計模式，我們可以用它來創(chuàng)建在域?qū)ο蠛蚒I表示層對象之間的區(qū)分。 同樣是架構(gòu)級別的，相同的地方在于他們都有一個表現(xiàn)層，但是他們不同的地方在于其他的兩個層。 在三層架構(gòu)中沒有定義Controller的概念。這是我認(rèn)為最不同的地方。而MVC也沒有把業(yè)務(wù)的邏輯訪問看成兩個層，這是采用三層架構(gòu)或MVC搭建程序最主要的區(qū)別。當(dāng)然了。在三層中也提到了Model，但是三層架構(gòu)中Model的概念與MVC中Model的概念是不一樣的，“三層”中典

11、型的Model層是以實體類構(gòu)成的，而MVC里，則是由業(yè)務(wù)邏輯與訪問數(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、可以降低層與層之間的依賴；4、有利于標(biāo)準(zhǔn)化；5、利于各層邏輯的復(fù)用。概括來說，分層式設(shè)計可以達(dá)至如下目的：分散關(guān)注、松散耦合、邏輯復(fù)用、標(biāo)準(zhǔn)定義。一個好的分層式結(jié)構(gòu)，可以使得開發(fā)人員的分工更加明確。一旦定義好各層次之間的接口，負(fù)責(zé)不同邏輯設(shè)計的

12、開發(fā)人員就可以分散關(guān)注，齊頭并進(jìn)。例如UI人員只需考慮用戶界面的體驗與操作，領(lǐng)域的設(shè)計人員可以僅關(guān)注業(yè)務(wù)邏輯的設(shè)計，而數(shù)據(jù)庫設(shè)計人員也不必為繁瑣的用戶交互而頭疼了。每個開發(fā)人員的任務(wù)得到了確認(rèn)，開發(fā)進(jìn)度就可以迅速的提高。松散耦合的好處是顯而易見的。如果一個系統(tǒng)沒有分層，那么各自的邏輯都緊緊糾纏在一起，彼此間相互依賴，誰都是不可替換的。一旦發(fā)生改變，則牽一發(fā)而動全身，對項目的影響極為嚴(yán)重。降低層與層間的依賴性，既可以良好地保證未來的可擴(kuò)展，在復(fù)用性上也是優(yōu)勢明顯。每個功能模塊一旦定義好統(tǒng)一的接口，就可以被各個模塊所調(diào)用，而不用為相同的功能進(jìn)行重復(fù)地開發(fā)。進(jìn)行好的分層式結(jié)構(gòu)設(shè)計，標(biāo)準(zhǔn)也是必不可少的

13、。只有在一定程度的標(biāo)準(zhǔn)化基礎(chǔ)上，這個系統(tǒng)才是可擴(kuò)展的，可替換的。而層與層之間的通信也必然保證了接口的標(biāo)準(zhǔn)化。如果是一個考試系統(tǒng)，考試合格的最低分?jǐn)?shù)線要改，只需要修改業(yè)務(wù)邏輯相對應(yīng)函數(shù)就可以了，只要此函數(shù)的入口參數(shù)和返回內(nèi)容不變，在客戶端不需作任何改動。在這里，看到了面向?qū)ο缶幊痰奶匦灾环庋b性的優(yōu)點，而這一點在開發(fā)大型應(yīng)用時尤其有用，可以把開發(fā)人員分成兩組，一組負(fù)責(zé)開發(fā)界面層，另一組負(fù)責(zé)開發(fā)商業(yè)邏輯層，雙方只要按照事先商定的函數(shù)接口，并行地開發(fā)就可以，而不必向從前那樣，后面的工作必須等前面的工作完成后才能開始。當(dāng)然，這樣的開發(fā)模式需要很好的項目協(xié)調(diào)和文檔作支持。如果現(xiàn)在用的系統(tǒng)是SQL SER

14、VER數(shù)據(jù)庫，由于各種原因要更改用ORACLE。如果不是三層結(jié)構(gòu)系統(tǒng)的話，可能需要改很多代碼，延長了開發(fā)周期?，F(xiàn)在使用了三層結(jié)構(gòu)，只要在加一個Oracle的數(shù)據(jù)訪問層。這樣就可以實現(xiàn)多數(shù)據(jù)庫了?，F(xiàn)在可能要做另外一個系統(tǒng)了，該系統(tǒng)也要對數(shù)據(jù)庫進(jìn)行操作。如果以前編寫過，這樣的一個數(shù)據(jù)層。只要把以前寫的那個數(shù)據(jù)層拷貝過來就可以了。實現(xiàn)代碼復(fù)用。從而減短了軟件的開發(fā)周期了。三層結(jié)構(gòu)的缺點“金無足赤，人無完人”，分層式結(jié)構(gòu)也不可避免具有一些缺陷：1、降低了系統(tǒng)的性能。這是不言而喻的。如果不采用分層式結(jié)構(gòu)，很多業(yè)務(wù)可以直接造訪數(shù)據(jù)庫，以此獲取相應(yīng)的數(shù)據(jù)，如今卻必須通過中間層來完成。2、有時會導(dǎo)致級聯(lián)的修改

15、。這種修改尤其體現(xiàn)在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設(shè)計符合分層式結(jié)構(gòu)，可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層中都增加相應(yīng)的代碼?；诮M件的三層B/S結(jié)構(gòu)概述在軟件體系架構(gòu)設(shè)計中，分層式結(jié)構(gòu)是最常見，也是最重要的一種結(jié)構(gòu)。微軟推薦的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層（又或成為領(lǐng)域?qū)樱?、表示層。三層結(jié)構(gòu)原理3個層次中，系統(tǒng)主要功能和業(yè)務(wù)邏輯都在業(yè)務(wù)邏輯層進(jìn)行處理。所謂三層體系結(jié)構(gòu)，是在客戶端與數(shù)據(jù)庫之間加入了一個“中間層”，也叫組件層。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機(jī)器就是三層體系結(jié)構(gòu)，也不僅僅有B/S應(yīng)用才是三層體

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

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

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

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