前言

　　首先非常感謝開源社群，在各位作者無私得奉獻下，我才有幸接觸CAP。在拜讀原始碼和理解設計原理過程中，發現CAP的原始碼是一個非常值得我們學習的程式碼。本人程式碼的基本框架採用簡單的DDD，在練習Demo中發現開啟事務的時候放在UOW實現，此時不需要ICapPublisher類，但是CAP需要，所以感覺呼叫起來多餘了。還有一點，當我開啟儀表盤的時候，發現儀表盤的定時統計會對資料庫造成一點壓力。由於本人對別人的開源產品不知道怎麼更改，因為沒有在生產環境中使用CAP，發現自己在guthub問的問題有點不清不楚的樣子，也不好意思去向CAP的作者提意見，所以就自己模仿了一個，就這樣NetSugar.Cap

支援對比

Dashboard對比

　　1、CAP當中Dashboard的程式碼與接收端、傳送端都是在同一個程式碼裡面，而NetSugar.Cap的Dashboard與邏輯程式碼是隔離的。在使用上CAP使用只需要引用一個包就足夠了。但是NetSugar.Cap的Dashboard提供了多個數據源的管理，可以配置多個數據源，並且每個資料來源可以單獨的配置讀連線和寫連線，儘可能的減少了開啟後臺之後對業務上使用資料庫的引用。

　　2、對一些訊息需要重新處理的處理，兩個都有一個Requeue操作，但是CAP執行Requeue操作時必須引用客戶端業務程式碼，但是NetSugar.Cap則不需要。因為NetSugar.Cap在Dashboard設計上，後臺的一些操作只是產生指令往資料庫插入的，然後等待業務端程式碼定時根據定義的ClientName去查詢對應的需要處理的記錄去處理。當然這裡客戶端程式碼上增加了定時查詢需要執行的指令的開銷。但是指令表與傳送訊息的表是分開的，所以消耗不大。

　　3、CAP可以多個數據庫節點通過consul進行統一檢視，但是NetSugar.Cap在一個數據源裡面只能檢視當前資料來源，沒有整合多個數據源的節點，但是可以在多個數據源之間進行隨意切換。

　　4、CAP對當日傳送和接收訊息的統計，NetSugar.Cap不支援。

　　5、CAP可以儀表盤地址進行動態配置，而NetSugar.Cap只能使用固定地址/CapDashboard/Home

業務程式碼使用對比

　　CAP是利用擴充套件IDbConnection（IMongoClient或者其它的）的方法去實現。

　　NetSugar.Cap是通過ITransactionCoordinator這個事務協調器，往裡面扔對應的事務或者Connection或者自定義實現ITransaction的類。

訂閱

　　1、CAP同一個專案中，同一個路由只能被一個方法去執行，但是NetSugar.Cap可以被多個訂閱者執行，但是同一個路由一個方法只能執行一次，能被多個方法執行。

　　2、方法引數繫結：

　　　　CAP只能有一個引數，但是NetSugar.Cap可以允許你有多個，兩者引數反序列化都是根據Json來反序列化的。

　　3、回撥

　　　　CAP執行傳送事件中帶回調方法，但是NetSugar.Cap不支援。NetSugar.Cap建議的是在訂閱方法中傳送一個執行完成的事件。

　　4、監聽繫結

　　　　CAP支援Controller和繼承ICapSubscribe的類，介面不行。NetSugar.Cap支援Controller和繼承ICapSubscribe的類和介面。

　　5、監聽斷線重連

　　　　NetSugar.Cap Rabbitmq會在網路閃斷之後會自動嘗試重新開啟監聽。

缺陷

　　NetSugar.Cap客戶端會定時的向資料庫中T_CapRequeue表查詢資料。T_CapClientNode、T_CapSubscriber重新整理心跳。

　　不支援同一個專案中使用兩個資料來源。

寫在最後

　　以上對比如有哪些欠缺或者錯誤還麻煩幫忙指出一下。特別是本人對CAP認知還不夠的地方，還請幫忙多指出，免得誤導了各位。NetSugar.Cap是我在學習了CAP程式碼之後寫的，沒有CAP就沒有NetSugar.Cap,非常感謝CAP的作者。想試試NetSugar.Cap的可以參考原始碼中的測試程式碼，NetSugar.Cap的Nuget也已經發布了。支援提意見，不支援吐槽。