软件的三层架构
全然看不懂
基于軟件三層架構的研究報告
引言
三層結構是傳統(tǒng)的客戶/server結構的發(fā)展，代表了企業(yè)級應用的未來，典型的有Web下的應用。多層結構和三層結構的含義是一樣的，僅僅是細節(jié)有所不同。之所以會有雙層、三層這些提法，是由于應用程序要解決三個層面的問題。
一、軟件架構和分層
（一）軟件架構（software architecture）
是一系列相關的抽象模式，用于指導大型軟件系統(tǒng)各個方面的設計。軟件架構是一個系統(tǒng)的草圖。軟件架構描寫敘述的對象是直接構成系統(tǒng)的抽象組件。各個組件之間的連接則明白和相對仔細地描寫敘述組件之間的通訊。在實現(xiàn)階段，這些抽象組件被細化為實際的組件，比方詳細某個類或者對象。在面向對象領域中，組件之間的連接通經常使用接口(計算機科學)來實現(xiàn)。軟件體系結構是構建計算機軟件實踐的基礎。與建筑師設定建筑項目的設計原則和目標，作為繪圖員繪圖的基礎一樣，一個軟件架構師或者系統(tǒng)架構師陳述軟件構架以作為滿足不同客戶需求的實際系統(tǒng)設計方案的基礎。
（二）分層
分層是表示將功能進行有序的分組：應用程序專用功能位于上層，跨越應用程序領域的功能位于中層，而配置環(huán)境專用功能位于低層。分層從邏輯上將子系統(tǒng)劃分成很多集合，而層間關系的形成要遵循一定的規(guī)則。通過分層，能夠限制子系統(tǒng)間的依賴關系，使系統(tǒng)以更松散的方式耦合，從而更易于維護。子系統(tǒng)的分組標準包括下面幾條規(guī)則可見度。各子系統(tǒng)僅僅能與同一層及其下一層的子系統(tǒng)存在依賴關系。
（三）使用分層架構開發(fā)的必要性
1、分層設計同意你切割功能進入不同區(qū)域。換句話說層在設計是就是邏輯組件的分組。比如，A層能夠訪問B層，但B層不能訪問A 層。
2、用分層的方法，以提高應用程序的可維護性，并使其更easy擴展，以提高性能。
（四）設計分層的原則
1、層意味著組建的邏輯分組。比如，對用戶界面，業(yè)務邏輯和數(shù)據(jù)訪問組建應該使用不同的不同的層。
2、在一個層內組建應該聚合的。如業(yè)務層組建僅應提供與業(yè)務邏輯相關的操作，而不是提供其它操作。
3、在設計的每個層接口時要考慮好物理邊界。假設通信擴月了物理邊界，使用基于消息操作；否則使用基于對象操作。
4、考慮使用接口類型（interface）來定義每層的接口。這將同意你創(chuàng)建該接口的不同實現(xiàn)，提高可測性。
5、對于Web應用程序，在表示層和業(yè)務邏輯層之間實現(xiàn)基于消息的接口是一個好主意，即使這兩層沒有跨越物理邊界。基于消息的接口更適合于無狀態(tài)的Web操作。
二、軟件的三層架構
（一）概述
在軟件體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務邏輯層（又或稱為領域層）、表示層。
1、表示層（UI）：通俗講就是展現(xiàn)給用戶的界面，即用戶在使用一個系統(tǒng)的時候他的所見所得。
2、業(yè)務邏輯層（BLL）：針對詳細問題的操作，也能夠說是對數(shù)據(jù)層的操作，對數(shù)據(jù)業(yè)務邏輯處理。
3、數(shù)據(jù)訪問層（DAL）：該層所做事務直接操作數(shù)據(jù)庫，針對數(shù)據(jù)的增添、刪除、改動、查找等。
（二）三層結構原理：
3個層次中，系統(tǒng)主要功能和業(yè)務邏輯都在業(yè)務邏輯層進行處理。
所謂三層體系結構，是在client與數(shù)據(jù)庫之間增加了一個“中間層”，也叫組件層。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結構，也不唯獨B/S應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一臺機器上。三層體系的應用程序將業(yè)務規(guī)則、數(shù)據(jù)訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，client不直接與數(shù)據(jù)庫進行交互，而是通過COM/DCOM通訊與中間層建立連接，再經由中間層與數(shù)據(jù)庫進行交互。
（三）各層的作用
數(shù)據(jù)訪問層：
有時候也稱為是持久層，其功能主要是負責數(shù)據(jù)庫的訪問，能夠訪問數(shù)據(jù)庫系統(tǒng)、二進制文件、文本文檔或是XML文檔。簡單的說法就是實現(xiàn)對數(shù)據(jù)表的Select，Insert，Update，Delete的操作。假設要增加ORM的元素，那么就會包含對象和數(shù)據(jù)表之間的mapping，以及對象實體的持久化。主要是對原始數(shù)據(jù)（數(shù)據(jù)庫或者文本文件等存放數(shù)據(jù)的形式）的操作層，而不是指原始數(shù)據(jù)，也就是說，是對數(shù)據(jù)的操作，而不是數(shù)據(jù)庫,詳細為業(yè)務邏輯層或表示層提供數(shù)據(jù)服務。
業(yè)務邏輯層：
主要是針對詳細的問題的操作，也能夠理解成對數(shù)據(jù)層的操作,對數(shù)據(jù)業(yè)務邏輯處理，假設說數(shù)據(jù)層是積木，那邏輯層就是對這些積木的搭建。業(yè)務邏輯層（Business Logic Layer）無疑是系統(tǒng)架構中體現(xiàn)核心價值的部分。它的關注點主要集中在業(yè)務規(guī)則的制定、業(yè)務流程的實現(xiàn)等與業(yè)務需求有關的系統(tǒng)設計，也即是說它是與系統(tǒng)所應對的領域（Domain）邏輯有關，非常多時候，也將業(yè)務邏輯層稱為領域層。比如Martin Fowler在《Patternsof Enterprise Application Architecture》一書中，將整個架構分為三個基本的層：表示層、領域層和數(shù)據(jù)源層。作為領域驅動設計的先驅Eric
Evans，對業(yè)務邏輯層作了更仔細地劃分，細分為應用層與領域層，通過分層進一步將領域邏輯與領域邏輯的解決方式分離。 業(yè)務邏輯層在體系架構中的位置非常關鍵，它處于數(shù)據(jù)訪問層與表示層中間，起到了數(shù)據(jù)交換中承上啟下的作用。由于層是一種弱耦合結構，層與層之間的依賴是向下的，底層對于上層而言是“無知”的，改變上層的設計對于其調用的底層而言沒有不論什么影響。假設在分層設計時，遵循了面向接口設計的思想，那么這樣的向下的依賴也應該是一種弱依賴關系。因而在不改變接口定義的前提下，理想的分層式架構，應該是一個支持可抽取、可替換的“抽屜”式架構。正由于如此，業(yè)務邏輯層的設計對于一個支持可擴展的架構尤為關鍵，由于它扮演了兩個不同的角色。對于數(shù)據(jù)訪問層而言，它是調用者；對于表示層而言，它卻是被調用者。依賴與被依賴的關系都糾結在業(yè)務邏輯層上，怎樣實現(xiàn)依賴關系的解耦，則是除了實現(xiàn)業(yè)務邏輯之外留給設計師的任務。
表示層：
位于最外層（最上層），離用戶近期。用于顯示數(shù)據(jù)和接收用戶輸入的數(shù)據(jù)，為用戶提供一種交互式操作的界面。主要表示WEB方式,也能夠表示成WINFORM方式,WEB方式也能夠表現(xiàn)成:aspx, 假設邏輯層相當強大和完好,不管表現(xiàn)層怎樣定義和更改,邏輯層都能完好地提供服務。
（四）詳細調用
微軟的DNA架構定義了三個層：表示層（presentation），業(yè)務邏輯層（business），和數(shù)據(jù)訪問層（data access）。詳細又分為：界面外觀層、界面規(guī)則層、業(yè)務接口層、業(yè)務邏輯層、實體層、數(shù)據(jù)訪問層、數(shù)據(jù)存儲層共七層，其詳細的調用如圖1所看到的:
（五）規(guī)則
1．系統(tǒng)各層次及層內部子層次之間都不得跨層調用。
2．Entityobject 在各個層之間傳遞數(shù)據(jù)。
3．須要在UI層綁定到列表的數(shù)據(jù)採用基于關系的DataSet傳遞，除此之外，應該使用Entityobject傳遞數(shù)據(jù)。
4．對于每個數(shù)據(jù)庫表（Table）都有一個DB Entity class與之相應，針對每個Entityclass都會有一個BEM Class與之相應。
5．有些跨數(shù)據(jù)庫或跨表的操作（如復雜的聯(lián)合查詢）也須要由對應的BEM Class來提供支持。
6．對于相對簡單的系統(tǒng)，能夠考慮將Business Function子層和Business Flow 子層合并為一個。
7．UI層和BL層禁止出現(xiàn)不論什么SQL語句。
三、優(yōu)缺點
（一）長處
1、開發(fā)者能夠僅僅關注整個結構中的當中某一層；
2、能夠非常easy的用新的實現(xiàn)來替換原有層次的實現(xiàn)；
3、能夠減少層與層之間的依賴；
4、有利于標準化；
5、利于各層邏輯的復用。
（二）缺點
1、減少了系統(tǒng)的性能。這是不言而喻的。假設不採用分層式結構，非常多業(yè)務能夠直接造訪數(shù)據(jù)庫，以此獲取對應的數(shù)據(jù)，現(xiàn)在卻必須通過中間層來完畢。
2、有時會導致級聯(lián)的改動。這樣的改動尤其體如今自上而下的方向。假設在表示層中須要添加一個功能，為保證其設計符合分層式結構，可能須要在對應的業(yè)務邏輯層和數(shù)據(jù)訪問層中都添加對應的代碼。
3、添加了開發(fā)成本。
（三）為什么要使用三層架構
對于一個簡單的應用程序來說，代碼量不是非常多的情況下，一層結構或二層結構開發(fā)全然夠用，沒有必要將其復雜化，假設對一個復雜的大型系統(tǒng)，設計為一層結構或二層結構開發(fā)，那么這種設計存在非常嚴重缺陷。以下會詳細介紹，分層開發(fā)事實上是為大型系統(tǒng)服務的。在開發(fā)過程中，0基礎程序人員出現(xiàn)相似的功能常常復制代碼，那么相同的代碼寫那么多次，不但使程序變得冗長，更不利于維護，一個小小的改動也許會涉及非常多頁面，常常導致異常的產生使程序不能正常執(zhí)行。最基本的面向對象的思想沒有得到絲毫的體現(xiàn)，打著面向對象的幌子卻依舊走著面向過程的道路。意識到這種問題，0基礎程序人員開始將程序中一些公用的處理程序寫成公共方法，封裝在類中，供其他程序調用。比如寫一個數(shù)據(jù)操作類，對數(shù)據(jù)操作進行合理封裝，在數(shù)據(jù)庫操作過程中，僅僅要類中的對應方法（數(shù)據(jù)加入、改動、查詢等）能夠完畢特定的數(shù)據(jù)操作，這就是數(shù)據(jù)訪問層，不用每次操作數(shù)據(jù)庫時都寫那些反復性
的數(shù)據(jù)庫操作代碼。在新的應用開發(fā)中，數(shù)據(jù)訪問層能夠直接拿來用。面向對象的三大特性之中的一個的封裝性在這里得到了非常好的體現(xiàn)。如今找到了面向對象的感覺，代碼量較曾經有了非常大的降低，并且改動的時候也比較方便，也實現(xiàn)了代碼的重用性。
四、與MVC的差別
MVC是三個單詞的縮寫，分別為：模型(Model),視圖(View)和控制Controller)。
MVC模式的目的就是實現(xiàn)Web系統(tǒng)的職能分工。 Model層實現(xiàn)系統(tǒng)中的業(yè)務邏輯，通常能夠用JavaBean或EJB來實現(xiàn)。
View層用于與用戶的交互，通經常使用JSP來實現(xiàn)。 Controller層是Model與View之間溝通的橋梁，它能夠分派用戶的請求并選擇恰當?shù)囊晥D以用于顯示，同一時候它也能夠解釋用戶的輸入并將它們映射為模型層可運行的操作。
相同是架構級別的，相同的地方在于他們都有一個表現(xiàn)層，可是他們不同的地方在于其它的兩個層。
在三層架構中未定義Controller的概念。而MVC也沒有把業(yè)務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程序最基本的差別。當然，在三層中也提到了Model，可是三層架構中Model的概念與MVC中Model的概念是不一樣的，“三層”中典型的Model層是以實體類構成的，而MVC里，則是由業(yè)務邏輯與訪問數(shù)據(jù)組成的。
五、小結
在軟件體系架構設計中，分層式結構是最常見，也是最重要的一種結構。 所以，分層式設計能夠達至例如以下目的：分散關注、松散耦合、邏輯復用、標準定義。一個好的分層式結構，能夠使得開發(fā)者的分工更加明白。一旦定義好各層次之間的接口，負責不同邏輯設計的開發(fā)者就能夠分散關注，齊頭并進。盡管三層架構仍有不可避免的缺陷，可是軟件分層結構使得代碼維護很方便，設計明白，各層獨立，專注自己擅長的領域。通過這次報告，對軟件體系結構又有了更深入的了解。
總結
- 上一篇： FATAL ERROR: CALL_AN
- 下一篇： Linux上搭建verdaccio私服