軟件分層應該如何分層？

一般信息系統中最常見的是如下所列的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、增加了開發成本。