ASP.NET Core 企業級開發架構簡介及框架彙總 （轉載）

ASP.NET Core 企業開發架構概述

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

• ASP.NET Core 企業開發架構概述
  • 1、 垂直方向架構
    • 1. 多層架構
      • 1.1 領域模型
      • 1.2 存儲倉庫
      • 1.3 服務
      • 1.4 UI
    • 2. 典型框架
      • 2.1 數據存儲框架
        • 2.1.1 數據訪問輔助
        • 2.1.2 對象-關係映射
      • 2.2 MVC 框架
        • 2.2.1 經典MVC模式
        • 2.2.2 後端MVC模式
        • 2.2.3 典型框架
        • 2.2.4 MVC模式總結
      • 2.3 IOC框架
        • 2.3.1 概念
        • 2.3.2 典型注入框架
  • 2、 水平方向架構
    • 1. SOA架構
      • 1.1 簡潔版架構
      • 1.2 服務的基本要素
      • 1.3 服務治理
    • 2. 微服務架構
      • 2.1 簡潔版架構
      • 2.2 服務的基本要素
      • 2.3 服務治理
    • 3. 總體式 vs SOA架構 vs 微服務架構
    • 4. SOA典型框架
    • 5. 微服務典型框架
    • 3、 總結

1、 垂直方向架構

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

2、 水平方向架構

多層架構適合總體式程序，即一個程序實現了系統所有功能。隨着企業規模愈來愈大，會面對不斷的新需求和需求改動，在一個程序中進行擴展變得愈來愈難以進行。同時面對大併發的業務請求，程序在一個進程或者多個進程中運行都難以克服一個低效運行的功能代碼形成的性能瓶頸。
人們找到了解決辦法：將程序功能分割成服務程序，各服務程序在水平方向上並行開發和部署，由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作平臺開發微服務程序。

3、 總結

對於總體式程序或者一個服務做爲總體式程序開發 ，能夠採用洋蔥模型架構。在處理數據時採用數據存取框架，對於UI能夠採用服務器端MVC和客戶端MVC框架。對於具備遺留程序的系統能夠採用SOA架構來整合系統功能；若是系統愈來愈複雜，負載壓力在不一樣程序功能上不平衡能夠採用微服務架構。在全新的即將成爲大型應用的系統採用微服務架構也是不錯的選擇。

參考文章：

http://blog.csdn.net/sinat_34093604/article/details/53082000

http://www.jdon.com/soa/integration-framework-comparison-spring.html

http://blog.csdn.net/qiumuxia0921/article/details/52713791

http://openwares.net/java/dip_ioc_di.html

http://www.cnblogs.com/summer7310/p/6394379.html

http://www.cnblogs.com/wangpenghui522/p/5430292.html

http://blog.csdn.net/zhengzhb/article/details/7190158

http://www.cnblogs.com/fanliang11/p/7191030.html

http://blog.csdn.net/orichisonic/article/details/48546061

 

 

原文鏈接  https://www.cnblogs.com/vipyoumay/p/7735750.html