企業開發框架包括垂直方向架構和水平方向架構。垂直方向架構是指一個應用程式的由下到上疊加多層的架構，同時這樣的程式又叫整體式程式。水平方向架構是指將大應用分成若干小的應用實現系統功能的架構，同時這樣的系統叫做分散式系統。在架構上java和.net世界都有優秀的框架支援構建垂直和水平方向架構。ASP.Net Core非常輕量且具有很高的效能，不僅適合做整體式程式，也非常適合做分散式系統。隨著微服務的興起，各種語言的混合應用是個趨勢。

　　轉載：http://www.cnblogs.com/vipyoumay/p/7735750.html

一、 垂直方向架構

1. 多層架構

分層架構通過程式包或者程式的隔離構建鬆耦合的應用。我們以最近流行的洋蔥架構模型進行分析，如圖

1.1 領域模型

包括領域實體/儲存介面/服務介面，是整個程式的核心。

• 貧血模型

如果把大量的業務邏輯委託給服務介面實現者，領域模型顯得很瘦小，就可以稱之為貧血模型。這種模型下的領域物件僅僅表示“狀態”。“行為”（也稱為邏輯、過程）放在了N層結構的Logic/Service/Manager層中。優點是易於理解和實現，缺點是隨著業務發展模型會難以表達業務領域。目前不少業內軟體架構是這種模式。

貧血模型的簡單圖示：

• 充血模型

如果在領域模型中實現主要的業務邏輯，把不方便實現的業務（比如匯率結算，地理座標解析等）委託給服務介面實現者，此時領域模型顯得粗壯，就可以稱之為充血模型。這種模型下的領域物件既表示“狀態”又有”行為“，領域物件之間還通過聚合在一個根（聚合根）

，然後由根物件保證狀態的一致性（類似於資料庫表之間的約束一致性）。優點是模型易於跟進業務發展，容易通過重構表達最新的業務領域；缺點是不易掌握。

充血模型的簡單圖示：

1.2 儲存倉庫

領域模型中的物件自從被創建出來後不會一直留在記憶體中活動，當它不活動時會被持久化到資料庫中，然後當需要的時候就會重建該物件；重建物件就是根據資料庫中已儲存的物件的狀態重新建立物件的過程。可見持久化和重建物件是一個和資料庫打交道的過程。從更廣義的角度來理解，程式會像集合一樣從某個類似集合的地方根據某個條件獲取一個或一些物件，往集合中新增物件或移除物件。也就是說，這就需要提供一種機制，可以提供類似集合的介面來幫助程式管理物件。倉儲就是基於這樣的思想被設計出來的。

貧血模型下的儲存倉庫：實現實體物件的CRUD.

充血模型下的儲存倉庫：建立聚合根物件,實體物件的建立/更新/刪除的行為由聚合根完成。

1.3 服務

一般有三種服務：應用服務、領域服務、基礎服務。

• 應用服務

  呼叫領域服務，形成工作流程，提供事物上下文。應用服務可以直接為UI提供服務或者直接作為API暴露出去。

• 領域服務

  在具體一個業務上下文中提供服務。比如訂單生成服務提供訂單的生成功能，訂單的跟蹤服務提供訂單的執行資訊。

• 基礎服務

  基礎服務提供的是和業務無直接關係的工具輔助服務。比如日誌，安全，通訊，事件匯流排等等。

1.4 UI

提供應用程式介面，支援使用者輸入。高效的UI開發往往會依賴UI框架，比如MVC框架。

UI框架比較多，比如MFC,WinForm,Asp.net WebForm,Asp.net MVC,Structs等等。

綜上：洋蔥模型的各層由外到內的單向依賴，簡單直接的降低了程式碼之間的耦合度。

2. 典型框架

2.1 資料儲存框架

2.1.1 資料訪問輔助

這類框架往往提供了一套操作連線/命令/結果集的介面。使用者先發起連線，發生sql命令，然後得到結果集以按行（又叫記錄）方式進行遍歷。不同的資料庫需要相應的資料庫驅動和實現，但對於使用者來說操作資料的方式都是一樣的。

優點：

1. 編寫原始sql，執行效率高。
2. 握有連線物件，可以自定義事物的發起，提交或者回滾。
3. 可以針對不同資料儲存方式定義資料訪問庫。
4. 一般比較輕量，依賴少。

缺點:

1. 編寫sql容易出錯，隨著資料庫的演變，sql的潛在錯誤必須依賴充分的單元測試才能消除。
2. 資料庫的演變，sql重構難度會逐漸增大。

框架	特點	開發語言
JDBC	簡單易學,上手快,非常靈活構建SQL，效率高	Java
ADO.NET	介面清晰，支援離線遍歷資料集，支援資料庫和非資料庫資料來源	C#

2.1.2 物件-關係對映

物件-關係對映（Object-Relational Mapping，簡稱ORM），以面向物件的開發方法實現資料的增刪改查。

優點：

1. 提高開發效率，降低開發成本
2. 使開發更加物件化
3. 可移植
4. 可以很方便地引入資料快取之類的附加功能

缺點：

1. 自動化進行關係資料庫的對映需要消耗系統性能。其實這裡的效能消耗還不大，一般來說都可以忽略之（除非在效能特別關鍵應用）。
2. 在處理多表聯查、where條件複雜之類的查詢時，ORM的語法會變得複雜。

典型框架：

框架	特點	開發語言
Dapper	半自動；輕量級；自己寫sql語句,可操作性強,小巧	C#
Entity Framework	全自動；較重量級；支援寫linq和原生sql，功能強大	C#
Hibernate	Hibernate功能強大，資料庫無關性好，O/R對映能力強,需要學習HQL,精通的難度高	Java
iBATIS	更名為MyBatis，入門簡單，即學即用;功能比較簡陋，需要受寫sql語句	Java / NET

2.2 MVC 框架

• Model

負責提供介面繫結的資料，以及業務邏輯處理。

• View

負責提供使用者和應用之間的互動介面。不同型別的應用互動介面不同，可以是桌面程式視窗和web頁面。

• Controller

負責收集使用者輸入事件，並分配事件給對該事件感興趣的模型處理。對MVC的理解難點在於控制器的解讀，在下面我們會用經典MVC模式和後端MVC模式分析。

2.2.1 經典MVC模式

這種模式大量用在複雜互動介面的桌面應用程式，比如MFC框架；以及web富應用框架中，比如AngularJS 1（儘管有人稱之為為MVVM框架）。

控制器把輸入事件通知給對該事件感興趣的模型（步驟3），模型更新自己的狀態並引起檢視更新（步驟4），然後將更新事件通知控制器（步驟5），此時如果有對該更新事件感興趣的模型會進一步進行處理（步驟6）。事實上控制器和模型之間構成了訂閱/釋出關係。

MVVM框架：把Controller變成了ViewModel，它與View進行雙向繫結：View的變動，自動反映在 ViewModel，反之亦然。

2.2.2 後端MVC模式

自web應用普及開來，湧現了不少後端MVC模式，比如JAVA的Structs,.NET的Asp.net MVC等。由於頁面在瀏覽器中顯示，使用者輸入通過http到達後端，在後端看來MVC模式預設如下圖所示：

與經典MVC模式不同，控制器直接獲得輸入事件（http請求），呼叫對應的模型，模型處理完後傳遞檢視物件（VO）給控制器，控制器找到合適的檢視並傳遞VO給檢視，檢視產生html/json/檔案流等資源，應用程式根據資源型別Response結果。通常後端MVC的控制負責的處理比較簡單；而複雜的使用者輸入可以用前端MVC框架實現（類似經典MVC模式）。

2.2.3 典型框架

框架	特點	開發語言	前後(端)
Asp.net MVC	支援WebForm和Razor	C#	後
Nancy	輕量，支援WebForm和Razor，路由更靈活	C#	後
Struts2	JSP上的MVC先驅，但比較重量，封裝簡陋	java	後
SpringMVC	開發效率和效能高於Struts2,100%零配置	java	後
AngularJS	功能完整，支援雙向繫結，開發效率高，執行效率一般，v2版本推翻v1,效能上提高，開發更元件化	js	前
React	思路新穎，運用Virtual Dom技術，效能高；但目標是UI元件，需配合其他庫搭建完整MVC框架	js	前
Vue	非常小巧，核心庫專注檢視層。需要搭建其他元件實現完整MVC框架	js	前

2.2.4 MVC模式總結

模型負責提供檢視資料和業務邏輯處理，檢視負責提供使用者互動介面，控制器將輸入事件分配到對該事件感興趣的模型。控制器居於中心位置，類似於功能膠水，但功能僅限於膠水是它不錯的定位；避免寫入過多業務邏輯程式碼使控制器變得複雜，難以維護。

MVC模式的價值在於更好的處理洋蔥架構的UI層。

2.3 IOC框架

2.3.1 概念

用現實生活中例子引入：由於汽車依賴輪胎，如果按照正向依賴，則汽車廠商需要根據輪胎供應商能提供的輪胎來定義自己的介面（螺絲，大小等）。但如果依賴倒置一下（讓輪胎廠商依賴汽車廠商），則汽車廠商只需要定義自己的介面（螺絲，大小等）由輪胎廠商去按照這個規格規範生產，就成為現在汽車行業的例子。這種依賴倒置是一個思想概念，需要一個容器來實現，這就是IOC框架。

• 依賴倒置(Dependency Inversion Principle, 英文縮寫為DIP)

從依賴具體類變換為依賴抽象就叫依賴倒置，這是一種設計原則。

• 控制反轉（Inversion of Control，英文縮寫為IoC）

依賴倒置的一種實現方式，通常用於構建框架，比如WinForm，WebForm程式中你可以自定義具體的視窗類，然後在視窗初始化和虛擬函式裡面寫程式碼，框架會按照自己的一套流程執行：啟動具體視窗，呼叫初始化方法，在不同的執行節點呼叫對應的虛擬函式。執行控制權始終在框架手中而不是我們寫的程式碼。

• 依賴注入(Dependency Injection，英文縮寫為DI)

依賴注入也是依賴倒置的一種具體實現，是類庫設計的一種常用模式。類庫基於依賴模式設計：呼叫者依賴於介面，而不是具體的實現，呼叫者在執行時被注入所依賴介面的具體實現。注入方法不在此處贅述。

• IOC框架

IOC框架包括了控制反轉和依賴注入功能。以下通過QA的方式來讀懂IOC框架：

Q: IOC的控制是對什麼的控制？

A: 是對應用程式中物件的建立和生命週期的控制。

Q: 正向控制是什麼樣子？

A: 由應用程式new物件，並在合適的時候釋放物件。

Q: 反轉控制是什麼樣子？

A: 物件的建立和生命週期管理由IOC框架控制，而不是應用程式控制，這種情形與正向控制相反就叫做反轉控制。

Q: 控制反轉帶來了什麼好處？

A: 控制反轉不僅減輕了應用程式的程式碼複雜性，更給IOC框架的擴充套件性帶來好處，比如IOC框架可以實現物件單例模式，多例模式，引入事物管理，日誌管理，安全管理等等功能，比如Spring產品家族。

Q: 依賴是什麼？

A: 依賴包括：臨時使用，關聯，聚合，組合，依賴關係從左到右增強。可以參考UML相關概念描述。

Q: 注入的目的是什麼？

A: 使得物件可以依賴抽象，而不是具體實現類。主要好處是讓應用程物件之間鬆耦合。

2.3.2 典型注入框架

框架	特點	開發語言
Unity	包含於微軟企業庫中，效能穩定	C#
Autofac	輕量，效能很高	C#
Spring	重量，功能強大	java

二、 水平方向架構

多層架構適合整體式程式，即一個程式實現了系統全部功能。隨著企業規模越來越大，會面對不斷的新需求和需求改動，在一個程式中進行擴充套件變得越來越難以進行。同時面對大併發的業務請求，程式在一個程序或者多個程序中執行都難以克服一個低效執行的功能程式碼造成的效能瓶頸。
人們找到了解決辦法：將程式功能分割成服務程式，各服務程式在水平方向上並行開發和部署，由API連線各服務，這種方式使降低服務之間的耦合，部署更加靈活，效能調優可以針對獨立的服務。

1. SOA架構

面向服務的體系結構（英語：service-oriented architecture）是構造分散式計算的應用程式的一種方法。它將應用程式功能作為服務提供給終端使用者或者其他服務使用。
它採用開放標準、與軟體資源進行互動並採用表示的標準方式。

1.1 簡潔版架構

1.2 服務的基本要素

• Policy(策略)

服務提供者有時候會要求服務消費者與某種策略通訊。比如要求消費者提供安全標識，才能獲取某項服務。

• Endpoint(終結點)

終結點是一個描述提供或者接受服務的方式，包括網路協議，域名或者IP,埠資訊。

• Contracts(合約)

服務合約是服務提供者（通常是遠端的）和使用者（客戶）之間使用合約語言（XML、JSON、Java Object等）約定資料輸入和資料輸出的一份協議。

• Messages(訊息)

服務提供的訊息，應滿足服務的合約。

1.3 服務治理

服務治理SOA最大的話題，涵蓋了以下內容：

• 服務定義（服務的範圍、介面和邊界）
• 服務部署生命週期（各個生命週期階段）
• 服務版本治理（包括相容性）
• 服務遷移（啟用和退役）
• 服務註冊中心（依賴關係）
• 服務訊息模型（規範資料模型）
• 服務監視（進行問題確定）
• 服務所有權（企業組織）
• 服務測試（重複測試）
• 服務安全（包括可接受的保護範圍）

為了解決以上問題，最為流行的做法在SOA架構中增加ESB（Enterprise Service Bus，即企業服務匯流排）整合。

2. 微服務架構

微服務是SOA的進化版本，把服務做到微型化。

2.1 簡潔版架構

2.2 服務的基本要素

微服務架構下通過REST API提供提服務，所以不強調策略和合約，只要服務提供方暴露終結點和提供訊息就足夠了。

2.3 服務治理

SOA會遇到的治理問題，在微服務中一樣會暴露出來。由於微服務系統中服務數量更多，生產環境中出現的各種問題更加突出。一部分人覺得微服務架構應該是去中心化，不需要ESB的中介作用，事實上為微服務的閘道器可以具備ESB的一些功能，比如安全檢查/事物管理/複雜的工作流程等功能。

3. 整體式 vs SOA架構 vs 微服務架構

框架	前期開發效率	迭代開發效率	擴充套件能力	維護性
整體式	高	中，通常越來越低	低	高
SOA架構	中	中，趨勢比較平穩	中	中
微服務架構	低	高，趨勢比較平穩	高	低

如果是小團隊，中小專案用整體式開發更好；如果有大量或者難以重構的遺留程式碼建議採用SOA架構；比如是全新的專案且預計將來會快速迭代成大專案則建議用微服務架構。

4. SOA典型框架

框架	特點	是否開源
WCF	微軟出品，目前僅在windows下執行。它支援HTTP、TCP、命名管道之間的單向和雙向訊息通訊，此外，在第三方擴充套件的幫助下，還支援任何基於訊息的傳輸格式。	客戶端開源
Spring Integration	基於Spring的輕量級開源框架，是一個乾淨、簡練的EAI手段，也是很好的ESB產品替代者。現在的ESB方案沉重且很難引入到一些環境中。Spring Integration則是一個功能強大、低摩擦的替代方案，它能溫和地解決一些最複雜的整合問題。	是
Mule ESB	它不是僅僅一個整合框架，而是一個包括一些額外功能的完整ESB ，Mule的Studio提供了一個很好的和直觀的視覺化設計。比Spring整合它更像是一個DSL。這一點很重要，如果整合邏輯比較複雜。	是
Apache Camel	Apache Camel幾乎和Mule ESB相同。你能想到的幾乎每一個技術，提供很多很多的元件（比Mule ESB甚至更多）。如果沒有可用的元件，你可以很容易地建立自己的元件	是

5. 微服務典型框架

	Dubbo	Spring Cloud	Surging
開發語言	Java	Java	C#
開發方	阿里	Spring社群	個人
維護狀態	不再繼續維護	活躍	一般
網際網路應用案例	阿里、京東、噹噹等	聯通 華為 東軟	暫無
基於協議	可選，預設dobbo	http	IPC
可用的語言	Java	所有語言	C#
分散式事物	否	否	否
無狀態部署	是	是	是
伺服器治理	服務發現、服務路由、服務負載均衡、服務列表、服務分組、服務依賴管理、服務權重、服務授權、服務直連、上下文隱式傳參、分組聚合、結果快取	除dubbo有的外：服務閘道器、斷路器、服務跟蹤、訊息匯流排、批量任務	提供高效能RPC遠端服務呼叫，採用Zookeeper、Consul作為surging服務的註冊中心，集成了雜湊，隨機，輪詢作為負載均衡的演算法，RPC整合採用的是netty框架，採用非同步傳輸
分散式配置	第三方	有	有
單元測試	支援	支援	未知

微服務思想重點在服務的微（自治，減少依賴）和治理（一個可靠安全的閘道器），它鼓勵混合應用順手的程式語言、開發框架，以減少高效開發與部署系統和軟硬體環境之間的摩擦，比如企業內有java和.net開發團隊則可以在Spring Cloud下用Asp.net core做平臺開發微服務程式。

三、 總結

對於整體式程式或者一個服務作為整體式程式開發 ，可以採用洋蔥模型架構。在處理資料時採用資料存取框架，對於UI可以採用伺服器端MVC和客戶端MVC框架。對於具有遺留程式的系統可以採用SOA架構來整合系統功能；如果系統越來越複雜，負載壓力在不同程式功能上不平衡可以採用微服務架構。在全新的即將成為大型應用的系統採用微服務架構也是不錯的選擇。