一、寫在前面
應用分層這件事情看起來很簡單，但每個程序員都有自己的一套，哪怕是初學者。如何讓一家公司的幾百個應用採用統一的分層結構，並得到大部分程序員的認同呢？這可不是件簡單的事情，接下來以我們真實案例與大家一起探討，先問大家兩個技術問題：
- 服務的調用代碼你覺得放到哪一層好呢？A表現層；B業務邏輯層；C數據層；D公共層。
- 如何組織好VO(View Object視圖對象)、BO(Business Object業務對象)、DO(Data Object數據對象)、DTO(Data Transfer Object數據傳輸對象)呢？
不同的人會有不同的答案，所以要統一公司應用分層，以減少開發維護學習成本。統一應用分層要可大可小、簡單易用、支持多種場景，我們採用IPO方式：I是Input、O是Output、P是Process，一進一出一處理。應用系統的本質是機器，是處理設備，一進一出一處理。
IPO原理圖
二、統一邏輯架構
統一應用分層的邏輯架構圖
職責說明：
| 層英文名 |
中文名 |
說明 |
|
| PresentationLayer |
表現層文件夾 |
上層向用戶提供服務，負責視圖展示。項目類型包括WebSite、WebForm、MVC、WCF、WebService等。 |
|
| BusinessLayer |
業務邏輯層文件夾 |
中間邏輯處理，負責應用系統的業務邏輯的處理。 |
|
| DataLayer |
數據訪問層文件夾 |
下層調用服務，負責數據資源提供方如數據庫、SOA、OpenAPI的交互。 |
|
| EntityLayer |
實體層文件夾 |
VO：View Object視圖對象；
DTO：Data Transfer Object數據傳輸對象；
BO：Business Object業務對象；
DO：Data Object數據對象；
在實際項目中，爲簡化設計可進行裁剪，BO和DO爲可選，DTO屬於服務項目類型，VO屬於網站項目類型，也不會同時存在。 |
|
| CommonLayer |
公共層文件夾 |
工具類庫，負責提供應用系統中常用的操作。 |
|
| TestLayer |
測試層文件夾 |
單元測試（可選），負責對其它類庫的自動化單元測試。 |
|
| |
|
|
|
- 文件夾分層法：應用分層採用文件夾方式的優點是可大可小、簡單易用、統一規範，可以包括5個項目，也可以包括50個項目，以滿足所有業務應用的多種不同場景；
- 調用規約：在開發過程中，需要遵循分層架構的約束，禁止跨層次的調用；
- 下層爲上層服務：以用戶爲中心，以目標爲導向。上層（業務邏輯層）需要什麼，下層（數據訪問層）提供什麼，而不是下層（數據訪問層）有什麼，就向上層（業務邏輯層）提供什麼；
- 實體層規約：DO是數據表對象，不是數據訪問層對象，不是隻能給數據訪問層使用；DTO是網絡傳輸對象，不是表現層對象，不是隻能給表現層使用；BO是內存計算邏輯對象，不是業務邏輯層對象，不是隻能給業務邏輯層使用 。如果僅限定在本層訪問，則導致單個應用內大量沒有價值的對象轉換。以用戶爲中心來設計實體類，可以減少無價值重複對象和無用轉換；
- U型訪問：下行時表現層是Input，業務邏輯層是Process，數據訪問層是Output。上行時數據訪問層是Input，業務邏輯層是Process, 表現層就Output。
三、我們的具體規範
此規範我們用了四年，牽涉幾百個應用，200多個研發人員，是一個成功的實踐。接下來就借用本文提供下載的TripOrderService、TripSellerMVCSite這兩個Demo來進行具體規範的說明，以下是截圖：
3.1、項目命名規則
項目命名規則：{產品線英文名全稱}.{子系統英文名全稱+應用名}.{項目職責英文名全稱}，如：Trip.Seller.DTO。
3.2、業務邏輯層的項目規範
規範說明：
1、項目名的命名規則：{產品線英文名全稱}.{子系統英文名全稱+應用名}.xxxBusiness，如上圖的Trip.Order.Business。
2、類名以Logic結尾，如上圖的OrderLogic.cs。
3.3、數據操作項目規範
規範說明：
1、各數據操作項目名根據使用什麼數據庫進行分類，然後以DB爲結尾，具體命名規則是：{產品線英文名全稱}.{子系統英文名全稱+應用名}.{使用什麼數據庫}DB，如上圖的Trip.Seller.MSSQLDB。
2、如果涉及到多個數據庫訪問的，那麼數據操作項目下的類文件需要按數據庫名稱（以DB爲結尾）創建文件夾分開，如上圖的TripOrderDB文件夾。
3、建議在應用中使用SQL語句，不使用存儲過程。在數據庫中不新增存儲過程，但舊的存儲過程可以繼續使用和修改。
4、分頁建議使用數據庫（如SQLServer）的最新特性進行分頁，並將每個分頁SQL直接寫到應用中。
3.4、實體類項目規範
規範說明：
1、DTO項目命名規則：{產品線英文名全稱}.{子系統英文名全稱+應用名}.DTO，如上圖的Trip.Order.DTO。
2、請求參數DTO實體類、響應DTO實體類存放規範以及其命名規則：
a、請求參數DTO實體類放在Request文件夾下，且命名規則爲：以Request結尾，如上圖的SearchOrderRequest.cs。
b、響應DTO實體類放在Response文件夾下，且命名規則爲：以Response結尾，如上圖的SearchOrderResponse.cs。
c、如果請求參數DTO實體類或響應DTO實體類的屬性中有對象或枚舉，那麼這些對象所屬的類、枚舉放在DTO項目的Common文件夾下。
3、如果請求參數DTO實體類、響應DTO實體類有基類要繼承，那麼建議爲基類取名爲RequestBase.cs、ResponseBase.cs。且這些基類直接放在DTO項目的Common文件夾下。
規範說明：
1、VO項目命名規則：{產品線英文名全稱}.{子系統英文名全稱+應用名}.ViewModel，如上圖的Trip.Seller.ViewModel。
2、各VO實體類，我們用Controller名作爲文件夾名進行分開，如上圖的Order文件夾。
3、VO實體類名的命名建議：
a、請求參數VO實體類以Input/Form/Query結尾，如上圖的SearchOrderInput.cs。
b、響應VO實體類以Output/List/Result結尾，如上圖的SearchOrderOutput.cs。
BO實體類名以Model爲結尾：
規範說明：
1、BO項目命名規則：{產品線英文名全稱}.{子系統英文名全稱+應用名}.BO，如上圖的Trip.Order.BO;
2、以Model結尾，如上圖的OrderModel.cs；
3、爲了簡化設計，BO項目爲可選，可在DO項目裏建文件夾。
規範說明：
1、DO項目命名規則：{產品線英文名全稱}.{子系統英文名全稱+應用名}.Entity，如上圖的Trip.Seller.Entity；
2、如果涉及到多個數據庫訪問的，那麼需要按數據庫名稱（以DB爲結尾）創建文件夾分開，如上圖的TripOrderDB文件夾；
3、表名+Entity結尾，如上圖的OrderEntity.cs；
4、DO是數據表對象，供單表CURD操作。對於多表查詢請求對象和返回對象，可定義新對象或使用現有對象（DTO/BO）來完成。
3.5、數據庫連接配置規範
規範說明：
1、數據庫連接的配置必須讀寫分離。
2、數據庫連接字符串建議加密處理。
3、數據庫連接配置名的命名規則：{以DB爲結尾的數據庫名稱}_讀寫類型，如：
TripOrderDB_SELECT、TripOrderDB_INSERT。
3.6、配置文件方面的規範
規範說明：
1、所有配置文件（除Web.config文件外）都必須放到Config文件夾下。
2、所有配置文件（除Web.config文件外）按不同環境區分開，具體命名規則是：{功能模塊英文名}.{環境英文簡稱名}.config，其中本地環境的英文簡稱名是Dev，測試環境的英文簡稱名是Test，正式環境的英文簡稱名是Prod，如上圖的AppSetting.Dev.config。
3、保持Web.config配置文件的乾淨，只留環境設置節點。
3.7、靜態資源文件方面的規範
規範說明：
1、公共的靜態資源文件（css、js、image等）放在另外的靜態站點中，統一由前端進行開發和維護。一般，css文件放在css文件夾下，js文件放在js文件夾下，image圖片文件放在img文件夾下。
2、與某項業務有關的js文件可以放到各自業務項目的表現層PresentationLayer下，以方便開發人員調試，js文件可放在項目的js文件夾下。
3、靜態資源文件必須使用版本號管理，以防更新後由於客戶端瀏覽器緩存而導致站點使用的依然是舊版本的靜態資源文件：
4.1、問題回答
問：服務的調用代碼應該放到哪一層呢？
A表現層、B業務邏輯層 、C數據層、D公共層。
答：我們的規範是統一放到數據資源訪問層即C。上層提供服務，下層調用服務，中間處理業務邏輯。
問：如何組織好VO(View Object視圖對象)、BO(Business Object業務對象)、DO(Data Object數據對象)、DTO(Data Transfer Object數據傳輸對象)呢？
答：通常有兩種做法，限定訪問範圍和不限定訪問範圍，實際項目中可根據需要選擇、折中或裁剪。我們使用後者，將EntityLayer作爲通用對象放到左側，具體可參考實體層規約：“DO是數據表對象，不是數據訪問層對象，不是隻能給數據訪問層使用；DTO是網絡傳輸對象，不是表現層對象，不是隻能給表現層使用；BO是內存計算邏輯對象，不是業務邏輯層對象，不是隻能給業務邏輯層使用
。如果僅限定在本層訪問，則導致單個應用內大量沒有價值的對象轉換。以用戶爲中心來設計實體類，可以減少無價值重複對象和無用轉換。”
問：應用分層範例代碼的編寫需要注意些什麼？
答：應用分層範例的代碼要想寫好，非常不容易，很容易引起爭議，很難讓所有人滿意
