軟體的三層架構

標籤：

全然看不懂

基於軟體三層架構的研究報告

引言

三層結構是傳統的客戶/server結構的發展，代表了企業級應用的未來，典型的有Web下的應用。多層結構和三層結構的含義是一樣的，僅僅是細節有所不同。之所以會有雙層、三層這些提法，是由於應用程式要解決三個層面的問題。

一、  軟體架構和分層

（一）  軟體架構（software architecture）

是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體架構描寫敘述的對象是直接構成系統的抽象組件。各個組件之間的串連則明白和相對仔細地描寫敘述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比方詳細某個類或者對象。在物件導向領域中，組件之間的串連通經常使用介面(電腦科學)來實現。 軟體體繫結構是構建電腦軟體實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員繪圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。

（二）分層

分層是表示將功能進行有序的分組：應用程式專用功能位於上層，跨越應用程式領域的功能位於中層，而配置環境專用功能位於低層。分層從邏輯上將子系統劃分成很多集合，而層間關係的形成要遵循一定的規則。通過分層，能夠限制子系統間的依賴關係，使系統以更鬆散的方式耦合，從而更易於維護。子系統的分組標準包括下面幾條規則可見度。各子系統僅僅能與同一層及其下一層的子系統存在依賴關係。

（三）使用分層架構開發的必要性

    1、分層設計同意你切割功能進入不同地區。換句話說層在設計是就是邏輯組件的分組。比如，A層能夠訪問B層，但B層不能訪問A 層。

    2、用分層的方法，以提高應用程式的可維護性，並使其更easy擴充，以提高效能。

（四）設計分層的原則

1、層意味著組建的邏輯分組。比如，對使用者介面，商務邏輯和資料訪問組建應該使用不同的不同的層。

2、在一個層內組建應該彙總的。如業務層組建僅應提供與商務邏輯相關的操作，而不是提供其它操作。

3、在設計的每個層介面時要考慮好物理邊界。假設通訊擴月了物理邊界，使用基於訊息作業；否則使用基於對象操作。

4、考慮使用介面類型（interface）來定義每層的介面。這將同意你建立該介面的不同實現，提高可測性。

5、對於Web應用程式，在展示層和商務邏輯層之間實現基於訊息的介面是一個好主意，即使這兩層沒有跨越物理邊界。基於訊息的介面更適合於無狀態的Web操作。

二、軟體的三層架構

（一）概述

在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：資料訪問層、商務邏輯層（又或稱為領域層）、展示層。

1、展示層（UI）：通俗講就是展現給使用者的介面，即使用者在使用一個系統的時候他的所見所得。 　　

2、商務邏輯層（BLL）：針對詳細問題的操作，也能夠說是對資料層的操作，對資料商務邏輯處理。 　　

3、資料訪問層（DAL）：該層所做事務直接操作資料庫，針對資料的增添、刪除、改動、尋找等。

　　

（二）三層結構原理： 　　

 

3個層次中，系統主要功能和商務邏輯都在商務邏輯層進行處理。 　　

所謂三層體繫結構，是在client與資料庫之間增加了一個“中介層”，也叫組件層。這裡所說的三層體系，不是指物理上的三層，不是簡單地放置三台機器就是三層體繫結構，也不唯獨B/S應用才是三層體繫結構，三層是指邏輯上的三層，即使這三個層放置到一台機器上。三層體系的應用程式將商務規則、資料訪問、合法性校正等工作放到了中介層進行處理。通常情況下，client不直接與資料庫進行互動，而是通過COM/DCOM通訊與中介層建立串連，再經由中介層與資料庫進行互動。

 　　

（三）各層的作用

 

資料訪問層：

有時候也稱為是持久層，其功能主要是負責資料庫的訪問，能夠訪問資料庫系統、二進位檔案、文字文件或是XML文檔。簡單的說法就是實現對資料表的Select，Insert，Update，Delete的操作。假設要增加ORM的元素，那麼就會包含對象和資料表之間的mapping，以及對象實體的持久化。主要是對未經處理資料（資料庫或者文字檔等存放資料的形式）的操作層，而不是指未經處理資料，也就是說，是對資料的操作，而不是資料庫,詳細為商務邏輯層或展示層提供資料服務。

 　　

商務邏輯層：

主要是針對詳細的問題的操作，也能夠理解成對資料層的操作,對資料商務邏輯處理，假設說資料層是積木，那邏輯層就是對這些積木的搭建。商務邏輯層（Business Logic Layer）無疑是系統架構中體現核心價值的部分。它的關注點主要集中在商務規則的制定、商務程序的實現等與業務需求有關的系統設計，也即是說它是與系統所應對的領域（Domain）邏輯有關，非常多時候，也將商務邏輯層稱為領域層。比如Martin Fowler在《Patternsof Enterprise Application Architecture》一書中，將整個架構分為三個基本的層：展示層、領域層和資料來源層。作為領域驅動設計的先驅Eric Evans，對商務邏輯層作了更仔細地劃分，細分為應用程式層與領域層，通過分層進一步將領域邏輯與領域邏輯的解決方式分離。 　　商務邏輯層在體系架構中的位置非常關鍵，它處於資料訪問層與展示層中間，起到了資料交換中承上啟下的作用。由於層是一種弱耦合結構，層與層之間的依賴是向下的，底層對於上層而言是“無知”的，改變上層的設計對於其調用的底層而言沒有不論什麼影響。假設在分層設計時，遵循了面向介面設計的思想，那麼這樣的向下的依賴也應該是一種弱依賴關係。因而在不改變介面定義的前提下，理想的分層式架構，應該是一個支援可抽取、可替換的“抽屜”式架構。正由於如此，商務邏輯層的設計對於一個支援可擴充的架構尤為關鍵，由於它扮演了兩個不同的角色。對於資料訪問層而言，它是調用者；對於展示層而言，它卻是被調用者。依賴與被依賴的關係都糾結在商務邏輯層上，怎樣實現依賴關係的解耦，則是除了實現商務邏輯之外留給設計師的任務。 　　

 

展示層：

位於最外層（最上層），離使用者近期。用於顯示資料和接收使用者輸入的資料，為使用者提供一種互動式操作的介面。主要表示WEB方式,也能夠表示成WINFORM方式,WEB方式也能夠表現成:aspx, 假設邏輯層相當強大和完好,不管表現層怎樣定義和更改,邏輯層都能完好地提供服務。

 　　

（四）詳細調用

 

微軟的DNA架構定義了三個層：展示層（presentation），商務邏輯層（business），和資料訪問層（data access）。詳細又分為：介面外觀層、介面規則層、業務介面層、商務邏輯層、實體層、資料訪問層、資料存放區層共七層，其詳細的調用1所看到的:

 

（五）規則

    1．系統各層次及層內部子層次之間都不得跨層調用。
    2．Entityobject 在各個層之間傳遞資料。
    3．須要在UI層綁定到列表的資料採用基於關係的DataSet傳遞，除此之外，應該使用Entityobject傳遞資料。
    4．對於每個資料庫表（Table）都有一個DB Entity class與之相應，針對每個Entityclass都會有一個BEM Class與之相應。
    5．有些跨資料庫或跨表的操作（如複雜的聯集查詢）也須要由對應的BEM Class來提供支援。
    6．對於相對簡單的系統，能夠考慮將Business Function子層和Business Flow 子層合并為一個。
    7．UI層和BL層禁止出現不論什麼SQL語句。

 

 

三、優缺點

（一）長處

1、開發人員能夠僅僅關注整個結構中的當中某一層；　　

2、能夠非常easy的用新的實現來替換原有層次的實現；　　

3、能夠減少層與層之間的依賴； 　　

4、有利於標準化； 　　

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

（二）缺點

1、減少了系統的效能。這是不言而喻的。假設不採用分層式結構，非常多業務能夠直接造訪資料庫，以此擷取對應的資料，現在卻必須通過中介層來完畢。 　　

2、有時會導致級聯的改動。這樣的改動尤其體如今自上而下的方向。假設在展示層中須要添加一個功能，為保證其設計符合分層式結構，可能須要在對應的商務邏輯層和資料訪問層中都添加對應的代碼。 　　

3、添加了開發成本。

 

（三）為什麼要使用三層架構

對於一個簡單的應用程式來說，代碼量不是非常多的情況下，一層結構或二層結構開發全然夠用，沒有必要將其複雜化，假設對一個複雜的大型系統，設計為一層結構或二層結構開發，那麼這種設計存在非常嚴重缺陷。以下會詳細介紹，分層開發事實上是為大型系統服務的。在開發過程中，0基礎程式人員出現相似的功能常常複製代碼，那麼相同的代碼寫那麼多次，不但使程式變得冗長，更不利於維護，一個小小的改動也許會涉及非常多頁面，常常導致異常的產生使程式不能正常執行。最基本的物件導向的思想沒有得到絲毫的體現，打著物件導向的幌子卻依舊走著面向過程的道路。意識到這種問題，0基礎程式人員開始將程式中一些公用的處理常式寫成公用方法，封裝在類中，供其他程式調用。比如寫一個資料操作類，對資料操作進行合理封裝，在資料庫操作過程中，僅僅要類中的對應方法（資料加入、改動、查詢等）能夠完畢特定的資料操作，這就是資料訪問層，不用每次操作資料庫時都寫那些反覆性 的資料庫作業碼。在新的應用開發中，資料訪問層能夠直接拿來用。物件導向的三大特性之中的一個的封裝性在這裡得到了非常好的體現。如今找到了物件導向的感覺，代碼量較曾經有了非常大的降低，並且改動的時候也比較方便，也實現了代碼的重用性。

四、與MVC的差別

    MVC是三個單詞的縮寫，分別為：模型(Model),視圖(View)和控制Controller)。 MVC模式的目的就是實現Web系統的職能分工。 Model層實現系統中的商務邏輯，通常能夠用JavaBean或EJB來實現。 View層用於與使用者的互動，通經常使用JSP來實現。 Controller層是Model與View之間溝通的橋樑，它能夠指派使用者的請求並選擇恰當的視圖以用於顯示，同一時候它也能夠解釋使用者的輸入並將它們映射為模型層可啟動並執行操作。

相同是架構層級的，相同的地方在於他們都有一個表現層，可是他們不同的地方在於其它的兩個層。 　　

在三層架構中未定義Controller的概念。而MVC也沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程式最基本的差別。當然，在三層中也提到了Model，可是三層架構中Model的概念與MVC中Model的概念是不一樣的，“三層”中典型的Model層是以實體類構成的，而MVC裡，則是由商務邏輯與訪問資料群組成的。

 

五、小結

在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。　所以，分層式設計能夠達至例如以下目的：分散關注、鬆散耦合、邏輯複用、標準定義。一個好的分層式結構，能夠使得開發人員的分工更加明白。一旦定義好各層次之間的介面，負責不同邏輯設計的開發人員就能夠分散關注，齊頭並進。儘管三層架構仍有不可避免的缺陷，可是軟體分層結構使得代碼維護很方便，設計明白，各層獨立，專註自己擅長的領域。通過這次報告，對軟體體繫結構又有了更深入的瞭解。

軟體的三層架構