一、  軟體架構和分層設計

（一）  軟體架構（software architecture）

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

（二）分層設計

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

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

    1、分層設計允許你分割功能進入不同區域。換句話說，層在設計中就是邏輯元件的分組。例如，A層可以訪問B層，但B層不能訪問A 層。

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

（四）設計分層的原則

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

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

    3、在設計的每一個層介面時要考慮好物理邊界。如果通訊擴充套件了物理邊界，使用基於訊息操作；否則使用基於物件操作。

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

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

二、軟體的三層架構

（一）概述

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

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

2、業務邏輯層（BLL）：針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。 　　

（二）三層結構原理： 　　

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

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

（三）各層的作用

資料訪問層：

有時候也稱為是持久層，其功能主要是負責資料庫的訪問，可以訪問資料庫系統、二進位制檔案、文字文件或是XML文件。簡單的說法就是實現對資料表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那麼就會包括物件和資料表之間的mapping，以及物件實體的持久化。主要是對原始資料（資料庫或者文字檔案等存放資料的形式）的操作層，而不是指原始資料，也就是說，是對資料的操作，而不是資料庫,具體為業務邏輯層或表示層提供資料服務。

業務邏輯層：

主要是針對具體的問題的操作，也可以理解成對資料層的操作,對資料業務邏輯處理，如果說資料層是積木，那邏輯層就是對這些積木的搭建。業務邏輯層（Business Logic Layer）無疑是系統架構中體現核心價值的部分。它的關注點主要集中在業務規則的制定、業務流程的實現等與業務需求有關的系統設計，也即是說它是與系統所應對的領域（Domain）邏輯有關，很多時候，也將業務邏輯層稱為領域層。例如Martin Fowler在《Patternsof Enterprise Application Architecture》一書中，將整個架構分為三個主要的層：表示層、領域層和資料來源層。作為領域驅動設計的先驅Eric Evans，對業務邏輯層作了更細緻地劃分，細分為應用層與領域層

一般資訊系統中最常見的是如下所列的4層：表示層，業務邏輯層，持久層，應用層。

模式介紹：

表示層(也稱為UI層)：主要對使用者的請求接受，以及資料的返回，為客戶端提供應用程式的訪問。應用層(也稱為服務層)：服務層的作用就是將表現層與業務邏輯層之間完成解耦。那麼表現層中就不會出現任何的業務程式碼，當然這樣帶來的好處也是顯而易見的，就是當我們修改業務層程式碼時，我們不需要修改表現層的程式碼，

當然如果服務層設計的不好，那麼可能會造成反效果。

業務邏輯層(也稱為領域層)：主要是針對具體的問題的操作，也可以理解成對資料層的操作，對資料業務邏輯處理，如果說資料層是積木，那邏輯層就是對這些積木的搭建。無疑是系統架構中體現核心價值的部分。它的關注點

主要集中在業務規則的制定、業務流程的實現等與業務需求有關的系統設計，也即是說它是與系統所應對的領域邏輯有關

資料訪問層(也稱為持久化層)：主要是針對非原始資料（資料庫或者文字檔案等存放資料的形式）的操作層，而不是指原始資料，也就是說，是對資料庫的操作，而不是資料，具體為業務邏輯層或表示層提供資料服務。

案例分析---SSH的分層：

1、在表示層中，首先透過JSP頁面展示資訊

2、在服務互動層中實現互動，負責傳送請求(Request)和接收響應(Response)，然後Struts根據配置檔案(struts-config.xml)將ActionServlet接收到的Request委派給相應的Action處理，然後action進行對請求處理並轉發給JSP頁面。

3、在業務邏輯層中，管理服務元件的Spring IoC容器負責向Struts2提供具體的Action物件，提供業務模型(Model)元件和該元件的協作物件資料處理(DAO)元件完成業務邏輯，並提供事務處理、緩衝池等容器元件以提升系統性能和保證資料的完整性。

4、在資料訪問層中，則依賴於Hibernate的物件化對映和資料庫互動，處理DAO元件請求的資料，並返回處理結果，給業務邏輯層。

以***重大技術需求為例

如果需求徵集頁面接到了一個新增需求的請求，使用者填完表單並提交，在web.xml配置了Struts2的攔截器，攔截表單提交請求，服務互動層根據Struts2的配置檔案去服務互動層層的DemandAction,尋找儲存的方法，該方法呼叫業務邏輯層

的方法demandService.Save(),業務邏輯層的這個方法又繼續呼叫資料持久層的方法把資料儲存到資料庫，呼叫完畢之後返回save，服務互動層根據返回的結果save由服務互動層呼叫業務層的顯示需求列表方法，業務層呼叫資料持久層數

資料庫讀取需求資訊，回到表現層顯示需求列表介面。Spring提供的IoC容器，我們可以將物件之間的依賴關係交由Spring進行控制管理服務元件的Spring IoC容器負責向Struts2提供具體的Action物件，提供業務模型(Model)元件和該元件的

協作物件資料處理(DAO)元件完成業務邏輯。

二）微軟推薦的分層式結構一般分為三層，從下至上分別為：資料訪問層、業務邏輯層（又或稱為領域層）、表示層。

表現層（UI）：通俗講就是展現給使用者的介面，用於顯示資料和接收使用者輸入的資料，為使用者提供一種互動式操作的介面。業務邏輯層（BLL）：針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。對於資料訪問層而言，它是呼叫者；對於表示層而言，它卻是被呼叫者。也將業務邏輯層稱為領域層。資料訪問層（DAL）：該層所做事務直接操作資料庫，針對資料的增、刪、改、查。如果要加入ORM的元素，那麼就會包括物件和資料表之間的mapping，以及物件實體的持久化。也稱為是持久層。資料訪問層中包含實體層（Model 實體層）

JavaWeb中典型的三層架構是：Jsp+Struts/spring+Hibernate的開發模式

簡單工廠模式與三層架構：

三層在簡單工廠的思想和基礎上，為了達到更好的可複用性，可擴充套件性，可維護性和靈活性，把簡單工廠的邏輯層進一步的分解，把邏輯層分解為邏輯判斷層和資料訪問層，讓她們彼此直接的耦合度達到最低。不管是簡單工廠還是三層架構，它們

一個餐館的例子，如果從買菜上菜到做菜都是一個人，那個人生病了這個餐館就不能營業了。如果有三個人分別負責招待客人、買菜、做菜，他們三個人有一個人生病的話，另外兩個做簡單的調整是可以營業的。也就是一層發生修改不會影響另外兩層的

工作。招待客人的相當於表示層，只負責招待客人，做菜的相當於業務邏輯層按照表示層給的引數做菜，買菜的相當於資料訪問層，只負責按照廚師給的單子買菜。

三）展示層，業務層，持久層，和資料庫層。

如表1-1，有時候，業務層和持久層會合併成單獨的一個業務層，尤其是持久層的邏輯繫結在業務層的元件當中。因此，有一些小的應用可能只有3層，一些有著更復雜的業務的大應用可能有5層或者更多的分層。與第一個四層不同的是，展示層負責處

理所有的介面展示以及互動邏輯，業務層負責處理請求對應的業務，持久層負責對資料的操作，資料層負責操作資料庫。

案例分析：

（參考https://blog.csdn.net/bboyfeiyu/article/details/45136299#t1）

為了演示分層架構是如何工作的，想象一個場景，如表1-4，使用者發出了一個請求要獲得客戶的資訊。黑色的箭頭是從資料庫中獲得使用者資料的請求流，紅色箭頭顯示使用者資料的返回流的方向。在這個例子中，使用者資訊由客戶資料和訂單陣列組成(客戶下的訂單)。

使用者介面只管接受請求以及顯示客戶資訊。它不管怎麼得到資料的，或者說得到這些資料要用到哪些資料表。如果使用者介面接到了一個查詢客戶資訊的請求，它就會轉發這個請求給使用者委託(Customer Delegate)模組。這個模組能找到業務層裡對應的模組處理

對應資料(約束關係)。業務層裡的customer object聚合了業務請求需要的所有資訊(在這個例子裡獲取客戶資訊)。這個模組呼叫持久層中的 customer dao 來得到客戶資訊，呼叫order dao來得到訂單資訊。這些模組會執行SQL語句，然後返回相應的資料給業務層。當 customer object收到資料以後，它就會聚合這些資料然後傳遞給 customer delegate,然後傳遞這些資料到customer screen 展示在使用者面前。

三 分層模式的特點使用場景：

一般的桌面應用程式電子商務Web應用程

模式特點：

每個模組必須屬於某個層次，為上層提供服務；同時委派任務給下層模組。任何一個模組，都不能逆層次呼叫；屬於下層的模組，不得呼叫（耦合）上層或上層次的模組。任何一個模組，都不得跨層次呼叫。

設計模式實現：

　　門面模式 ——我們對於每個模組或者每個層次都會設計一個“門面”來降低耦合的複雜程度。

　　策略模式——抽象層次會隱藏底層的實現細節，這就是策略模式最基本的設計，我們往往會把上層作為功能介面，下層作為可選的策略來實現。

優點

1、開發人員可以只關注整個結構中的其中某一層；

2、可以很容易的用新的實現來替換原有層次的實現；

3、可以降低層與層之間的依賴；

4、有利於標準化；

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

6、結構更加的明確

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

缺點

1、降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須透過中間層來完成。

2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料訪問層中都增加相應的程式碼。

3、增加了開發成本。