EF Core-1

帶着問題去思考，你們好！

前幾天瞭解到EF Core的開發模式：DB First（數據庫優先）,Model First（模式優先），Code First（代碼優先）。

我所接觸的大可能是DB First。若是你們瞭解的話，有些開源後臺項目，基本都會有後二者，由於方便你們更快的去使用部署起來後臺。

在建議的Layered ['leɪəd] Architecture [ˈɑːrkɪtektʃər]模式中,---表示層，業務層和數據層，其後Evans分析並引入兩個關鍵變化。

一：將關注點放到layer上，而不是tier。layer是應用程序組件之間的邏輯分隔,而tier是物理上不一樣的應用程序和服務器。

二：識別的層數分爲4各層-表示層-應用層-領域層和基礎結構層

 

 

 

 

總體式應用程序

　　自底向下設計，咱們都是圍繞着數據模型來進行開發設計，其中的過程以及尤爲依賴數據模型的用戶界面和體驗。

　　 在總體式應用程序中，數據從底部的持久化存儲到前端，而後在返回。

　　根據分層架構，咱們都知道，從存儲到前端以及從前端到存儲。咱們不該該考慮把應用程序堆棧分紅兩部分嗎？獨立處理命令堆棧和讀堆棧對於開發是否是更加有效果呢？因此NOSql存儲來了，使得經典的RDBMS系統開始支持XML和JSON。這也正式Command and Query Responsibility Segregation(CQRS)模式的使用。

 

 

 

 

 

以上是結合CQRS設計的分層架構模式

CQRS方法

CQRS不是萬能的，重要的是他的思想。

　　有經驗的開發人員知道。建立一個理想的數據模型，使其可以將關係數據模型的原則和最終用戶實際須要的視圖的複雜性結合起來是很困難的。若是隻有一個應用程序堆棧，就只能有一個面向持久化的數據模型，可是須要調整這個模型，使其可以有效的知足前端的需求。特別是與某種方法學（如領域驅動設計的額外的抽象層結合起來時）,後端（業務邏輯和數據訪問邏輯）的設計很容易變得一團亂。

　　以上問題。CORS經過將設計問題分解爲兩個較小的問題，新應用程序架構設計解決問題，並不釋施加外部約束，使設計變得更加簡單。具備不一樣的堆棧的好處是，容易爲實現名利和查詢使用不一樣的對象模型。有必要，能夠爲命令使用一個完整的領域模型，爲表示使用一個定製的普通的數據傳輸對象，可能這些對象從SQL查詢具體化的，須要多個表示前端，只須要額外建立讀模型。總體複雜度是個體複雜度的和，而不是笛卡爾積。

　　1：不一樣的數據庫

　　分解成不一樣的堆棧有一些問題,兩個堆棧同步問題，數據命令寫入可以被一致地讀回？根據自身業務，CQRS實現能夠基於一種兩種數據庫，若是使用一個共享數據庫，共享數據庫確保了經典的ACID一致性，只須要在讀堆棧中的普通查詢作一些額外的工做。

　　性能和擴展行，能夠考慮爲命令堆棧和讀堆棧使用不一樣的持久化端點。

　　

 

何時用CQRS？

這是一種模式，CQRS架構模式主要是被設計來解決高併發業務場景的性能問題。

基礎結構層的構成

基礎結構層是與使用具體的技術相關的全部東西，包括數據持久化O/RM框架（EF），外部的Web服務，特定的安全API，日誌記錄，跟蹤，IOC容器，緩存等。最突出的是組件的持久化層，也就是數據訪問層。

持久化層 緩存層 外部服務這些已經很是成熟，不在這裏贅述。