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容器，快取等，最突出的是組件的持久化層，也就是資料訪問層，

持久化層快取層外部服務這些已經非常成熟，不在這里贅述，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/5546.html

標籤：SQL Server

上一篇：完美解決MSSQL安裝問題“Polybase要求安裝Oracle JRE 7更新51（64位）”方案

下一篇：分享攢了多年的mssql腳本