大叔跟誰學外掛篇

1、 Redis 兩種集群模式的對比及高可用集群的實現(xiàn)4主從模式4高可用模式6Redis 的哨兵7Redis-sentinel 的實際意義7Redis3.0 以后的 Cluster 集群8二EF技術剖析10Code實體的設計10數(shù)據(jù)上下文(共享對象與實例對象的選擇)10自動初始化（Initializer 初始化的幾種方式）10數(shù)據(jù)遷移（Migrations 如何使用及其重要作用）11實體關系(一對一，一對多，多對多)12延時加載和include 立即加載13重寫 SaveChanges 解決并發(fā). 14manderceptor 實現(xiàn)讀寫分離，實體主鍵泛型化的實際意義等14三MVC技術剖析15MVC

2、 各層分工15Http 請求的過程（以會話）. 15ViewM,DTO,M,EntityM的闡述15關于實體校驗技術，關于 action 的返回值與頁面的綁定15關于頁面到 action 傳值的幾種方式16關于路由的配置17關于Bundles技術17關于 global.asax 可以干的事17方法技術在過濾器上的體現(xiàn)等18ControllerFactory 的介紹18ControllerBuilder 的介紹18Controller 的激活19四 CQRS/ES 在模式的實現(xiàn)22CQRS+ES 美麗的圖畫22命令查詢模式介紹與實現(xiàn)22傳統(tǒng)的 Curd 方式23CQRS25CQRS 的優(yōu)勢28E

3、vent Sourcing 是什么30CQRS 與 ES 關系30領域事件與命令事件區(qū)別31領域實體里發(fā)出的事件31應用層里令事件31領域層里的領域事件32五Lind.DDD.Plugsin 插件模式的實現(xiàn)33為什么要設計 PlugsIn33哪些組件可以被提長為 PlugsIn33模塊的自動化與使用33Autofac 是實現(xiàn) PlugsIn 的基礎33六Lind.DDD.LindMQ 消息對象的實現(xiàn)33傳統(tǒng)消息隊列的概念33.Net 里的Queue 類型33Redis 里集成的Queue33使用輪詢實現(xiàn)消息的消費33LindMQ 的生產者33LindMQ 的消息處理者33LindMQ 的消費者

4、33LindMQ 在Redis 里的數(shù)據(jù)結構33七大話權限_URL 權限_按鈕權限和數(shù)據(jù)限33Lind 里集成了比較完善的 url 權限，作權限和數(shù)據(jù)集的權限。33權限從登陸開始35URL 權限的介紹35為 URL 權限添限36URL 權限承載的數(shù)據(jù)結構36作)權限的介紹36按鈕權限的數(shù)據(jù)結構37UI 上如何控制按鈕的顯示37Controller 層如何控制按鈕的操作權限37數(shù)據(jù)限的設計38八Lind.DDD.Authorization機制與 Http 請求的. 38是為了什么38URL要解決哪些問題38Lind.DDD.Utils.HttpHelper 提供了完整的 Http 請求38Lin

5、d 對加密參數(shù)的自動化構建38服務端配置相關介紹39Lind 服務端自動化校驗的實現(xiàn)39九Lind.DDD 中租戶審核者編輯者軟刪除的集成39ILogicDeleteBehavor 接口39IAuditedBehavor 接口39IModifyBehavor 接口39IOwnerBehavor 接口39十分布式消息樹的介紹39ttp 請求的前與后39使用 mongodb 來日志41樹的介紹41消息樹的介紹42鏈表的介紹43消息鏈的介紹43 Redis 兩種集群模式的對比及高可用集群的實現(xiàn)主從模式通過 redis.conf 去配置主從關系，由 redis 進程負責數(shù)據(jù)的同步，當主掛了后，從不能自

6、動切換成主，這是最致命了，可以說，主從模式主要是在負載均衡上考慮的，可以提高 redis 吞吐量，但對于高可用上，沒有任務作為！服務端各個從服務器配置如何（6789 為主節(jié)點的端口，6380 為自己節(jié)點的端口）相關配置：代碼的使用：字符串參數(shù)對象參數(shù)高可用模式主要介紹使用 StackExchange.Redis 進行 Twemproxy（文中簡稱 TW）服務的連接過程，事務上，對于來說，需要理解一下它的物理架構，它類似于Nugix，主要實現(xiàn)的是請求轉發(fā)，但它還有一個重要的功能，那就是自動分片，這對于大數(shù)據(jù)是很必要的，你的服務器需要橫向擴展時，不需要告訴客戶端，這是一種很理解化的設計模式，當然，

7、也對于Redis 來說，在配置 TW 之后，是可以被全美支持的！1.關于 tw 和Redis 集群的設計圖2.關于 StackExchange.Redis 驅動對 TW 的支持3.關于 Redis3.0 以后的 Cluster 集群4.關于 Redis 的主從模式的集群5.關于 Redis 的哨兵 Sentinel客戶端代碼： 服務服務器加后， 無法被客戶端連接， 在 年 月號，推出新版本， 此時，stackexchange.redis 驅動已經支持了的 AUTH 指令Redis 的哨兵Redis 集群的主從模式有個最大的弊端，就是當主 master 掛了之前，它的 slave 從服務器無法為

8、主，而在redis-sentinel 出現(xiàn)之后，有效的解決了這個問題，它相當于是一個投票者或者哨兵，它時刻監(jiān)視著 redis 集群的各個服務器，當主 master 掛了之后，它將進行投票進行新 master 的，一般地會建立多個 redis-sentinel服務器，它們都會進行主 master 的工作，當多個 redis-sentinal 都選擇同一個主之后，這個主才有效！Redis-sentinel 的實際意義對于使用方來說，有了 redis-sentinel 就等于有了當前的 redis-master，即的數(shù)據(jù)就知道向哪臺服務器寫入了（其它 slave 都是從 master 同步的數(shù)據(jù)），

9、這對于使用客戶端的開發(fā)來說，直接redis-sentinel 的返回值即可，當然前提是你不要求橫向擴展，不要求分片，當然，這對一個大型數(shù)據(jù)來說，是可笑的，我們當然需要擴展，對大數(shù)據(jù)當然要進行自動分片，所有需要為 redis-sentinal 再加一層的服務器，如Twemproxy，有了，在連接redis 時，直接連接的地址即可，這會自動分片，并且自redis-sentinel 并連接真實的 redis-master 服務器！對于的 Sentinel 來說，只能對它進行一些簡單的操作，如訂閱服務，同時，它為開放了很多事件，供在外面調用Redis3.0 以后的 Cluster 集群主要特點：1):

10、節(jié)點自動發(fā)現(xiàn)2):slave-master,集群容錯3):Hot resharding:分片4):集群管理:cluster5):基于配置(nodes-port.conf)的集群管理6):ASK 轉向/MOVED 轉向機制.架構圖：二 EF技術剖析Code實體的設計基類，會有一些公用的屬性，如果屬性不需要被序列化成表的字段，就為屬性加NotMapped 特性即可。數(shù)據(jù)上下文(共享對象與實例對象的選擇)ObjectContext,DbContext 是前者的子類，封裝和改寫了前臺的一些方法。這個問題說法分云，但大叔認為數(shù)據(jù)上下文屬于輕量級對象，可以使用 using 實例對象(using 作用域結果

11、后，對象被回收)，或者使用全局定義的實例對象（私用的，獨立的對于每個線程是線程，HTTP 請求開始到結束，Http線程會被回收，第二個用戶頁面，有可能拿到相同 ID 的線程，但它們的對象是不同的，有可能已經被 GC回收了），而不要使用共享對象(sic,threadsic) 所有線程使用同一個數(shù)據(jù)上下文,因為共享對象會多線程的，即數(shù)據(jù)上下文在被多線程共用時，會出現(xiàn)問題，這句話希望大家記住！自動初始化（Initializer 初始化的幾種方式）在 code模式里，提供了數(shù)據(jù)庫自動建立，數(shù)據(jù)表內容自己添加等操作，一般情況下可以通過幾下幾種方式進行實現(xiàn)：Web.config 中定義初始化文件二Migr

12、ations 的 Configuration 里的 Seed 方法，進行初始化數(shù)據(jù)遷移（Migrations 如何使用及其重要作用）當使用 Code開發(fā)項目時，數(shù)據(jù)庫是后被生成的，而當你的模型發(fā)生變化時，EF 給的解決方法有兩種應對，其一是自己刪除原庫，生產成的數(shù)據(jù)庫；其二是發(fā)出一個數(shù)據(jù)庫變更的異常，提醒開發(fā)去更新自己的數(shù)據(jù)庫。提倡的一定是第二種，因為誰也不想和數(shù)據(jù)去開這個玩笑！當開啟數(shù)據(jù)遷移后，項目里會多一個 Migrations 文件夾下面看一下數(shù)據(jù)遷移令，在包管理器命令窗口可以輸入而對于生產環(huán)境，可以使用命令生成對應的 SQL 語句，拿到服務器上 SQL 上去執(zhí)行即可，下面看一下代碼：U

13、pdate-Database -Script -SourceMigration: $InitialDatabase -Migration:manage實體關系(一對一，一對多，多對多)一對一：主鍵對主鍵，一張大表拆成多去管理，根據(jù)自己的業(yè)務去拆分，如用戶表可能被拆成主表和擴展信息表及登陸信息表等。一對多：分為自關聯(lián)一對多（一張表）和主從表一對多等，下面看一下圖自關聯(lián)多表關聯(lián)多對多關系：一般是指兩個表，相互都是一對多，這時把它們的關系抽象成第三張表去，這種表稱為關系表，或者叫多對多關系表。多對多關系表的操作：添加，刪除，更新（刪除后再添加）EF 里將多對多關系表成兩個一對多關系，即每個實體里有一

14、個集合屬性的外鍵多對多關系只針對兩個實體，多個表不能實現(xiàn) EF 的多對多關系！延時加載和 include 立即加載立即加載，就是查詢時直接把外鍵數(shù)據(jù)加載進來！延時加載：就是通過Linq 返回結果集時，外鍵表不去加載，而是在 UI 層加載每一條數(shù)據(jù)時，再去連接數(shù)據(jù)庫，加載對應的數(shù)據(jù)，這個好處就是按需加載，缺點也很明顯，無疑加大了數(shù)據(jù)庫連接次數(shù)，對于列表數(shù)據(jù)加載，杜絕這種方式！重寫 SaveChanges 解決并發(fā)當 EF 的 insert,update,delete 將變更提交到數(shù)據(jù)庫之前，先要保存到時一個數(shù)據(jù)狀態(tài)區(qū)域里，由的savechanges 進行提交，發(fā)到數(shù)據(jù)庫端。而在進行提交過程中如果

15、出現(xiàn)異常，如并發(fā)，數(shù)據(jù)有效性校驗失敗等問題，都會引起數(shù)據(jù)操作失敗，這時，可以通過重寫 savechanges 有效的避免并發(fā)的情況，而且可以對數(shù)據(jù)有效性校驗進行日志的！manderceptor 實現(xiàn)讀寫分離，實體主鍵泛型化的實際意義等manderceptor 是 EF6 新添加的組件，主要用來當前的LINQ 語句，然后可以對LINQ 語句進行加工，最后再發(fā)到數(shù)據(jù)庫！三 MVC技術剖析MVC 各層分工層架構設計中，被放到時了層上。M：可以被分為 ViewM和 DataM（如果不希望這個 datam的字段持久化成數(shù)據(jù)表字段，需要為它添加NotMapped 特性）,MVC 里的M大叔認為是這兩個的并

16、集。View：視圖，用來呈現(xiàn)表現(xiàn)，它有 aspx 和 razor 兩種引擎，在 mvc2.0 之后建議使用 razor 引擎。View里的數(shù)據(jù)來自 controller,由 controller 負責數(shù)據(jù)返回到 View 上。Controller：控制器，MVC 模式的，用來進行表現(xiàn)層的各種邏輯控制，包括數(shù)據(jù)校驗，業(yè)務層方法選擇，視圖渲染方式選擇等。Http 請求的過程（以會話）HTTP 請求發(fā)起-建立會話ses-返回客戶端sesID-在客戶端cookeis 里-之后客戶端請求會帶上sesID-到 Action-ActionResult-渲染視圖。ViewM,DTO,M,EntityM的闡述V

17、iewM:是頁面顯示的數(shù)據(jù)的實體對象（層添加）DTO:用于進行數(shù)據(jù)傳輸，像在 web api,WCF,WS 進行通訊時，封裝的數(shù)據(jù)對象就是DTO（應用層或者業(yè)務層）M:是業(yè)務模型，它為了實現(xiàn)某個業(yè)務而組裝的對象，它可以是幾張數(shù)據(jù)表的組合；而在面向領域驅動的設計里，M又叫領域模型，里面會有領域實體，值對象和領域事件等。EntityM(DataM)：實體模型，與數(shù)據(jù)表一一對應，是最底層的模型.關于實體校驗技術，關于 action 的返回值與頁面的綁定實體上各屬性的校驗，使用特性實現(xiàn)實體整個校驗證，可以添加 meta 校驗實體關于頁面到 action 傳值的幾種方式路由轉值(RouteData)方法

18、叁數(shù)會被 get 請求參數(shù)自動對應起來表單傳值表單的 key/value 會被自動成參數(shù)實體對象關于路由的配置可以通過配置路由，然后產生不同樣式的關于Bundles技術Bundle 技術是里一個亮點，它類似一個模版的概念，將事先定義好的一套 css,js 等文件動態(tài)加載，讓程序開發(fā)不需要單個文件去，由直接在 bundle 中進行配置即可，而且可以動態(tài)加載版本的文件關于 global.asax 可以干的事用來加載一些初始化的動作，如訂閱一些全局事件，注入全局路由，全局過濾器等。方法技術在過濾器上的體現(xiàn)等主要用在了 action 過 濾 器 這 塊 ， 由 框 架 為實現(xiàn) 的 方 法， 像比 較

19、熟 悉 的ActionFilterAttribute,AuthorizeAttribute 等。ControllerFactory 的介紹ASP.NET MVC 為 Controller 的激活定義相應的相應的工廠，其統(tǒng)稱為 ControllerFactory，所有的ControllerFactory 實現(xiàn)了接口 IControllerFactory 接口。如下面的代碼片斷所示，Controller 對象的激活最終最終通過 IControllerFactory 的 CreateController 方法來完成，該方法的兩個參數(shù)分別表示當前請求上下文和從路由信息中獲取的 Controller 的

20、名稱（最初來源于請求地址）。ControllerBuilder 的介紹用于激活 Controller 對象的 ControllerFactory 最終通過 ControllerBuilder到 ASP.NET MVC 應用中。如下面的代碼所示，ControllerBuilder 定義了一個靜態(tài)只讀屬性 Current 返回當前 ControllerBuilder 對象，這是針對整個 Web 應用的全局對象。兩個 SetControllerFactory 方法重載用于ControllerFactory 的類型或者實例，而 GetControllerFactory 方法返回一個具體的 Contro

21、llerFactory 對象。Controller 的激活Controller 類型的激活目標 Controller 對象的前提是能夠正確出對應的 Controller 類型。對于 DefaultControllerFactory 來，用于目標 Controller 類型的信息包括：通過與當前請求匹配的路由對象生成的 RouteData（其中包含Controller 的名稱和命名空間）和包含在當前 ControllerBuilder 中名空間。很對讀者可以首先想到的是通過Controller 名稱得到對應的類型，并通過命名空間組成 Controller 類型的全名，最后遍歷所有程序集以此名稱去

22、加載相應的類型即可。這貌似一個不錯的解決方案，實際上則完全不可行。了作為請求地址 URL 一部分的 Controller 名稱是不區(qū)分大小寫的，而類型名稱則是區(qū)分大小的；不論是路由時指定名空間還是當前 ControllerBuilder 的默認命名空間，有可能是包含統(tǒng)配符（*）。由于不能通過給定的 Controller 名稱和命名空間得到 Controller 的真實類型名稱，自然就不可能通過名稱去Controller 的類型了。ASP.NET MVC 的 Controller 激活系統(tǒng)反其道而行之。 它先遍歷通過 BuildManager 的靜態(tài)方法 GetReferencedAssembs

23、 方法得到的編譯Web 應用所使用的程序集，通過反射得到所有實現(xiàn)了接口 IController的類型，最后通過給定的 Controller 的名稱和命名空間作為匹配條件在這個預先獲取的類型列表中得到目標Controller 的類型。Controller 加載過程創(chuàng)建 Controller 對象獲取 Controller 類型以后，接下來就要進行 Controller 對象的創(chuàng)建。在DefaultControllerFactory 類的源碼中可以看到，同 ControllerBuilder 類似，該類的構造函數(shù)中也實例化了一個SingleServiceResolver 對象，按照之前介紹的方法，

24、一眼就可以看出，該對象是利用默認值的方式提供了一個DefaultControllerActivator 對象。實際上DefaultControllerFactory 類僅實現(xiàn)了類型的搜索，對象的真正創(chuàng)建過程需要由DefaultControllerActivator 類來完成，默認情況下，DefaultControllerActivator 創(chuàng)建 Controller 的過程是很簡單的，因為它實際上使用的是一個叫做DefauependencyResolver 的類來進行 Controller 創(chuàng)建的，在該類內部直接調用 Activator.CreateInstanerviceType)方法完成對

25、象的實例化。從 DefaultControllerFactory 和DefaultControllerActivator 這兩個類的創(chuàng)建過程可以發(fā)現(xiàn)，MVC 提供了多種方式(IDependencyResolver 方式、委托方式 、默認值方式)來提供對象，因此在對 MVC 相關模塊進行擴展的時候，也有多種方式可以采用。Controller 的作為激活 Controller 對象的 ControllerFactory 不僅僅用于創(chuàng)建目標 Controller 對象，還具有兩個額外的功能，即通過 ReleaseController 方法對激活的 Controller 對象進行和回收，以及通過Get

26、ControllerSesBehavior 返回用于控制當前會話狀態(tài)行為的 SesSeBehavior 枚舉。對于默認使用 DefaultControllerFactory 來說，針對 Controller 對象的操作很簡單：如果 Controller 類型實現(xiàn)了 IDisable 接口，則直接調用其Dise 方法即可；否則直接忽略。這個邏輯也實現(xiàn)在了自定義的 ReflelctionControllerFactory 中。四 CQRS/ES 在模式的實現(xiàn)CQRS+ES 美麗的圖畫命令查詢模式介紹與實現(xiàn)在常用的三層架構中，通常都是通過數(shù)據(jù)層來修改或者查詢數(shù)據(jù)，一般修改和查詢使用的是相同的實體。在

27、一些業(yè)務邏輯簡單的系統(tǒng)中可能沒問題，但是隨著系統(tǒng)邏輯變得復雜，并發(fā)量變大，這種設計就會出現(xiàn)一些性能瓶頸。雖然在整個數(shù)據(jù)庫上可以做讀寫分離的設計，但在業(yè)務上如果在讀寫方面混合在一起的話，仍然會出現(xiàn)一些問題。命令查詢職責分離模式(d Query Responsibility Segregation，CQRS)，該模式從業(yè)務上分離修改(d，增，刪，改，會對系統(tǒng)狀態(tài)進行修改)和查詢（Query，查，不會對系統(tǒng)狀態(tài)進行修改)的行為。從而使得邏輯更加清晰，便于對不同部分 進行針對性的優(yōu)化。文章首先簡要介紹了傳統(tǒng)的 CRUD 方式存在，接著介紹了 CQRS 模式，最后以一個簡單的系統(tǒng)演示了如何實現(xiàn) CQRS

28、 模式。要談到讀寫操作，首先來看傳統(tǒng)的 CRUD。選自文章傳統(tǒng)的 Curd 方式在以前的管理系統(tǒng)中，命令(d，通常用來更新數(shù)據(jù)，操作 DB)和查詢(Query)通常使用的是在數(shù)據(jù)層中 Reitory 中的實體對象(這些對象是對 DB 中表的)，這些實體有可能是 SQLServer 中的一行數(shù)據(jù)或者多個表。通常對數(shù)據(jù)庫執(zhí)行的增，刪，改，查（CRUD）都是針對的系統(tǒng)的實體對象。如通過數(shù)據(jù)層獲取數(shù)據(jù)，然后通過數(shù)據(jù)傳輸對象DTO 傳給表現(xiàn)層。或者， 用戶需要更新數(shù)據(jù)，通過DTO 對象將數(shù)據(jù)傳給 M，然后通過數(shù)據(jù)層寫回數(shù)據(jù)庫，系統(tǒng)中的所有交互都是和數(shù)據(jù)查詢和有關，可以認為是數(shù)據(jù)驅動 （Data-Driv

29、en）的，如下圖：選自文章傳統(tǒng)方式一些問題在事務寫時，讀數(shù)據(jù)會被阻塞使用同一個對象實體來進行數(shù)據(jù)庫讀寫可能會太粗糙，大多數(shù)情況下，比如編輯的時候可能只需要更新個別字段，但是卻需要將整個對象都穿進去，有些字段其實是不需要更新的。在查詢的時候在表現(xiàn)層可能只需要個別字段，但是需要查詢和返回整個實體對象。使用同一實體對象對同一數(shù)據(jù)進行讀寫操作的時候，可能會遇到資源競爭的情況，經常要處理的鎖，在寫入數(shù)據(jù)的時候，需要加鎖。數(shù)據(jù)的時候需要判斷是否允許臟讀（臟讀，幻讀都是出現(xiàn)在事務里，當事務級別比較低出現(xiàn)的一種數(shù)據(jù)異常。如果你的事務級別比“序列化（）”就不會出現(xiàn)上面，當事務沒有結束時，這些被影響的數(shù)據(jù)不能被）

30、。這樣使得系統(tǒng)的邏輯性和復雜性增加，并且會對系統(tǒng)吞吐量的增長會產生影響。直接與數(shù)據(jù)庫進行交互在大數(shù)據(jù)量同時的情況下可能會影響性能和響應性，并且可能會產生性能瓶頸。由于同一實體對象都會在讀寫操作中用到，所以對于安全和權限的管理會變得比較復雜。這里面很重要的一個問題是，系統(tǒng)中的讀寫頻率比，是偏向讀，還是偏向寫，就如同一般的數(shù)據(jù)結構在查找和修改上時間復雜度不 一樣，在設計系統(tǒng)的結構時也需要考慮這樣。解決方法就是經常用到的對數(shù)據(jù)庫進行讀寫分離。 讓主數(shù)據(jù)庫處理事務性的增，刪，改操作(Insert,Update,Delete)操作，讓從數(shù)據(jù)庫處理查詢操作(Select操作)，數(shù)據(jù)庫被用 來將事務性操作導

31、致的變更同步到集群中的從數(shù)據(jù)庫。這只是從 DB 角度處理了讀寫分離，但是從業(yè)務或者系統(tǒng)上面讀和寫仍然是存放在一起的。他們都是用的同一個實體對象。要從業(yè)務上將讀和寫分離，就是接下來要介紹令查詢職責分離模式。CQRSCQRS 最早來自于 Betrand Meyer（Eiffel 語言之父，開-閉原則 OCP 提出者）在Object-Oriented SoftwareConstruction 這本書中提到的一種 命令查詢分離 (d Query Separation,CQS) 的概念。其基本在于，任何一個對象的方法可以分為兩大類：命令(d):不返回任何結果(void)，但會改變對象的狀態(tài)。查詢(Que

32、ry):返回結果，但是不會改變對象的狀態(tài)，對系統(tǒng)沒有副作用。查詢的設計命令的設計CQRS 使用分離的接口將數(shù)據(jù)查詢操作(Queries)和數(shù)據(jù)修改操作(ds)分離開來，這也意味著在查詢和更新過程中使用的數(shù)據(jù)模型也是不一樣的。這樣讀和寫邏輯就開來了。寫庫和讀庫職責清晰主數(shù)據(jù)庫處理 );*，從庫處理 8，從庫的的結構可以和主庫的結構完全一樣，也可以不一樣，從庫主要用來進行只讀的查詢操作。在數(shù)量上從庫的個數(shù)也可以根據(jù)查詢的規(guī)模進行擴展，在業(yè)務邏輯上，也可以根據(jù)專題從主庫中劃分出不同的從庫。從庫也可以實現(xiàn)成“報表數(shù)據(jù)庫”，根據(jù)查詢的業(yè)務需求，從主庫中抽取一些必要的數(shù)據(jù)生成一系列查詢報表來。使用報表數(shù)據(jù)

33、庫的一些優(yōu)點通?？梢允沟貌樵冏兊酶雍唵胃咝В豪锸聞罩械?，也是從寫庫讀的報表數(shù)據(jù)庫的結構和數(shù)據(jù)表會針對常用的查詢請求進行設計。報表數(shù)據(jù)庫數(shù)據(jù)庫通常會去正規(guī)化，一些冗余而減少必要的 0UOT 等聯(lián)合查詢操作，使得查詢簡化和高效，一些在主數(shù)據(jù)庫中用不到的數(shù)據(jù)信息，在報表數(shù)據(jù)庫可以不用?？梢詫蟊頂?shù)據(jù)庫重構優(yōu)化，而不用去改變操作數(shù)據(jù)庫。對報表數(shù)據(jù)庫數(shù)據(jù)庫的查詢不會給操作數(shù)據(jù)庫帶來任何壓力?？梢葬槍Σ煌牟樵冋埱蠼⒉煌膱蟊頂?shù)據(jù)庫庫。當然這也有一些缺點，比如從庫數(shù)據(jù)的更新。如果使用 SQLServer，本身也提供了一些如故障轉移和機制來方便部署。CQRS 的優(yōu)勢分工明確，可以負責不同的部分將業(yè)務上令

34、和查詢的職責分離能夠提高系統(tǒng)的性能、可擴展性和安全性。并且在系統(tǒng)的演化中能夠保持高度的靈活性，能夠防止出現(xiàn) CRUD 模式中，對查詢或者修改中的某一方進行改動，導致另一方出現(xiàn)問題的情況。邏輯清晰，能夠看到系統(tǒng)中的那些行為或者操作導致了系統(tǒng)的狀態(tài)變化?？梢詮臄?shù)據(jù)驅動(Data-Driven) 轉到任務驅動(Task-Driven)以及事件驅動(Event-Driven).什么時候考慮使用 CQRS 模式：當在業(yè)務邏輯層有很多操作需要相同的實體或者對象進行操作的時候。CQRS 使得可以對讀和寫定義不同的實體和方法，從而可以減少或者避免對某一方面的更改造成對于一些基于任務的用戶交互系統(tǒng)，通常這類系統(tǒng)

35、會引導用戶通過一系列復雜的步驟和操作，通常會需要一些復雜的領域模型，并且整個團隊已經熟悉領域 驅動設計技術。寫模型有很多和業(yè)務邏輯相關令操作的堆，輸入驗證，業(yè)務邏輯驗證來保證數(shù)據(jù)的一致性。讀模型沒有業(yè)務邏輯以及驗證堆，僅僅是返回 DTO 對象為視圖模型提供數(shù)據(jù)。讀模型最終和寫模型相一致。適用于一些需要對查詢性能和寫入性能分開進行優(yōu)化的系統(tǒng)，尤其是讀/寫比非常高的系統(tǒng)，橫向擴展是必須的。比如，在很多系統(tǒng)中讀操作的請求時遠大 于寫操作。為適應這種場景，可以考慮將寫模型出來單獨擴展，而將寫模型運行在一個或者少數(shù)幾個實例上。少量的寫模型實例能夠減少合并發(fā)生的情況適用于一些團隊中，一些有經驗的開發(fā)者可以

36、關注復雜的領域模型，這些用到寫操作，而另一些經驗較少的開發(fā)者可以關注用戶界面上的讀模型。對于系統(tǒng)在將來會隨著時間不段演化，有可能會包含不同版本的模型，或者業(yè)務規(guī)則經常變化的系統(tǒng)需要和其他系統(tǒng)整合，特別是需要和事件溯源 Event Sourcing 進行整合的系統(tǒng)，這樣子系統(tǒng)的臨時異常不會影響整個系統(tǒng)的其他部分。什么時候不適宜使用 CQRS：領域模型或者業(yè)務邏輯比較簡單，這種情況下使用 CQRS 會把系統(tǒng)搞復雜。對于簡單的，CRUD 模式的用戶界面以及與之相關的數(shù)據(jù)操作已經足夠的話，沒必要使用 CQRS，這些都是一個簡單的對數(shù)據(jù)進行增刪改查。不適合在整個系統(tǒng)中到處使用該模式。在整個數(shù)據(jù)管理場景中

37、的特定模塊中 CQRS 可能比較有用。但是在有些地方使用 CQRS 會增加系統(tǒng)不必要的復雜性。Event Sourcing 是什么EventSourcing 又叫事件溯源，簡稱 ES，一個對象從創(chuàng)建開始到消亡會經歷很多事件，以前是在每次對象參與完一個業(yè)務動作后把對象的狀態(tài)持久化保存到數(shù)據(jù)庫中，也就是說的 數(shù)據(jù)庫中的數(shù)據(jù)是反映了對象的當前的狀態(tài)。而事件溯源則相反，不是保存對象的狀態(tài)，而是保存這個對象所經歷的每個事件，所有的由對象產生的事件會 按照時間先后順序有序的存放在數(shù)據(jù)庫中?？梢钥闯觯录菰吹倪@種做法是更符合事實觀的，因為它完整的描述了對象的整個生命周期過程中所經歷的所有事件。CQRS 與

38、 ES 關系在 CQRS 中，查詢方面，直接通過方法查詢數(shù)據(jù)庫，然后通過 DTO 將數(shù)據(jù)返回。在操作(d)方面，是通過發(fā)送d 實現(xiàn)，由 dBus 處理特定的d，然后由d 將特定的 Event 發(fā)布到EventBus 上，然后 EventBus 使用特定的 Handler 來處理事件，執(zhí)行一些諸如，修改，刪除，更新等操作。這里，所有與d 相關的操作都通過 Event 實現(xiàn)。這樣可以通過Event 來系統(tǒng)的運行歷史，并且能夠方便的回滾到某一歷史狀態(tài)。Event Sourcing 就是用來進行和管理事件的。領域事件與命令事件區(qū)別領域事件Event 是在領域實體中定義和觸發(fā)的，它不關心使用哪種持久化機

39、制去保存數(shù)據(jù)；而命令事件dEvent，主要是數(shù)據(jù)表進行添加，刪除和修改，與業(yè)務沒有直接的關系，另外在數(shù)據(jù)結構設計上，領域事件被發(fā)送到領域總線中等待執(zhí)行；而命令事件被發(fā)送到 ES 中等待執(zhí)行的。層服務層命令事件領域實體領域事件領域實體里發(fā)出的事件領取事件一般在領域層出現(xiàn)，用來處理某種業(yè)務相關的信息，而命令事件主要在應用層出現(xiàn)，它一般直接操作數(shù)據(jù)庫或者業(yè)務層某個方法，主要是用來持久化數(shù)據(jù)的；而在命令事件里，如果希望調用某個業(yè)務請求，一般是通過調用對應的領域實體的事件實現(xiàn)的，例如：應用層里令事件領域層里的領域事件五 Lind.DDD.Plugsin 插件模式的實現(xiàn)為什么要設計 PlugsIn哪些組件

40、可以被提長為 PlugsIn模塊的自動化與使用Autofac 是實現(xiàn) PlugsIn 的基礎六 Lind.DDD.LindMQ 消息對象的實現(xiàn)傳統(tǒng)消息隊列的概念.Net 里的 Queue 類型Redis 里集成的 Queue使用輪詢實現(xiàn)消息的消費LindMQ 的生產者LindMQ 的消息處理者LindMQ 的消費者LindMQ 在Redis 里的數(shù)據(jù)結構七 大話權限_URL 權限_按鈕權限和數(shù)據(jù)限Lind 里集成了比較完善的url 權限，作權限和數(shù)據(jù)集的權限。URL圖示URL 上的按鈕圖示數(shù)據(jù)限圖示權限從登陸開始直接使用 mvc 和 api 的器實現(xiàn)，即 AuthorizeAttribute，

41、然后到全局的過濾器容器里，如果你的Action不希望被，可以為它添加AllowAnonymousAttribute 特性即可排除。URL 權限的介紹主要用戶控制當前的 URL 地址是否被給指定角色，當一個用戶登陸后，被持有一個角色，在Lind.ddd.manager 里可以為這個角色分配菜單（URL），然后在的過濾器上去判斷，當前登陸的用戶的角色是否有這個菜單 URI 的權限，限就可以頁面；沒限就出現(xiàn)未的頁面。為 URL 權限添限添加的方法也是采用全局的，直接到全局過濾器容器里，AllowAnonymousAttribute 用來忽略。URL 權限承載的數(shù)據(jù)結構作)權限的介紹在業(yè)務上的某些按鈕

42、進行， 按 鈕權 限就 是角 色的 操作權限， 在 Lind.DDD.Manager 里使用mands 數(shù)據(jù)表來，默認在 lind 初始化時會添加一些基本的權限，業(yè)務可以根據(jù)自己的需要去擴展自己的權限，權限最多可以擴展 60 個左右，采用長整型，運算采用運算！按鈕權限的數(shù)據(jù)結構UI 上如何控制按鈕的顯示UI 上面采用的 HtmlHelper 的擴展方法的方式去封裝，然后開發(fā)根據(jù)需要去使用即可，為方法傳入一個 HTML 代碼的委托即可。Controller 層如何控制按鈕的操作權限在 controller 的 action 里，可以稱它為后端，之前在 UI 端只是起到了顯示按鈕的作用，事實上它并

43、不安全，它并不能限制一般T 插件的，所以需要在后端同樣進行設計，即添加一個對象的操作權限特性ActionAuthority數(shù)據(jù)限的設計是一套比較通用的，關于數(shù)據(jù)集的權限設計，主要是將業(yè)務的數(shù)據(jù)與系統(tǒng)的角色進行一個關聯(lián)，的角色對應的可以被的業(yè)務的值，當業(yè)務用戶登陸后，需要在數(shù)據(jù)表查詢，看是否有某種數(shù)據(jù)的權限即可。八 Lind.DDD.Authorization機制與 Http 請求的主要對當前比較流行的進行設計，的校驗機制，的請求封裝， 集成了GET,T,PUT 和DELETE，客戶端只需要配置自己的 appKey 和 passKey 即可，而服務端方面只要添加對應的全局 Filter 即可實現(xiàn)安全校驗。是為了什么URL要解決哪些問題Lind.DDD.Utils.HttpHelper 提供了完整的 Http 請求Lind 對加密參數(shù)的自動化構建服務端配置相關介紹2OTJ 服務端自動化校驗的實現(xiàn)九 2OTJ * 中租戶審