初識ABP vNext（1）：開篇計劃&基礎知識

時間 2020-08-19

原文原文鏈接

Tips：本篇已加入系列文章閱讀目錄，可點擊查看更多相關文章。html

前言

ABP vNext（如下簡稱ABP）的前身是asp.net boilerplate（老版abp），它不是一個簡單的版本更新，而是徹底基於.NET Core的重寫。以前有據說過ABP框架，可是一直沒有去詳細瞭解。最近認真學習了一下，準備記錄下本身的一些心得，計劃分爲3部分來進行：vue

ABP基礎（就是官網上一些基本的功能）
ABP實戰（使用ABP+vue開發一個簡單項目）
ABP模塊化（微服務簡單介紹）

首先，這是以一個0基礎的視角去寫的，因此會比較基礎，適合新手。文中若是有不對的地方，你們能夠幫我指出來相互學習。。。git

開始

ABP官網：https://www.abp.io/github

ABP GitHub：https://github.com/abpframework/abp數據庫

要學習ABP，首先確定要認真看一下官方的文檔，雖然目前官方文檔還不完整；而後對哪一部分不理解的，能夠適當的閱讀一下源碼。架構

ABP是基於DDD:Domain-Driven Design（領域驅動設計）去開發的，固然框架自己不強制你使用DDD，可是他建議把DDD做爲最佳實踐。若是瞭解DDD，而且使用過老版本abp的話，看官方文檔可能就比較輕鬆，反之則會比較吃力。。。首先DDD理論就很是抽象和複雜，要深入理解它並不容易；其次是ABP內部使用了不少開源組件，好比EF Core，IdentityServer4，Autofac，AutoMapper，Swagger等等，因此也須要對這些組件有所瞭解。app

本篇簡單介紹一下ABP官方文檔上一些重要的關鍵字，先理解這些關鍵字，才能更好的進一步學習。框架

審計(Audit)

審計是用於追蹤數據變化的過程。平時開發中，你必定常常見到相似建立時間、建立人、修改時間、修改人等屬性，這些屬性就是用於數據審計。ABP框架提供了一些接口和基類來標準化這些屬性，並自動設置它們的值；而且ABP提供了一個可擴展的審計日誌系統，自動化的根據約定記錄審計日誌，並提供配置來控制審計日誌的級別。ABP中審計相關基類/接口有：IAuditedObject、AuditedEntity、AuditedAggregateRoot等等。asp.net

本地化(Localization)

使應用程序支持多國語言。ABP的本地化系統與ASP.NET Core的本地化兼容。分佈式

事件總線(Event Bus)

事件總線是對觀察者（發佈-訂閱）模式的一種實現。它是一種集中式事件處理機制，容許不一樣的組件之間進行彼此通訊而又不須要相互依賴，達到一種解耦的目的。

若是沒有接觸過Event Bus，可能不太好理解。一個不太恰當的例子：A須要租房，B須要把房子租出去，A想直接找到B是比較困難的，A也不想去認識B，因此纔有房產中介C，C就是Event Bus；B提早跟C說個人房子須要出租，A跟C說我給你錢你幫我租一個房，那麼C很容易就幫A找到B完成租房，A甚至不須要知道B是誰，這裏A就是事件的發佈者，B是事件的訂閱者。ABP支持本地Event Bus和分佈式Event Bus。

多租戶(multi-tenancy technology)

多租戶是一種軟件架構技術，這種架構可讓多個租戶共用相同的系統，而且能夠確保各租戶間數據的隔離性。相信不少人都遇到過相似需求，同一個系統中根據不一樣客戶區分數據；一般咱們會在數據庫表中增長一個客戶Id做爲標識，或者根據不一樣客戶讀取不一樣的數據庫，這都是多租戶數據隔離的實現方式，想本身很好的實現多租戶仍是很繁瑣的。ABP的多租戶模塊提供了建立多租戶應用程序的基本功能，能夠很輕鬆的幫你實現多租戶。

DDD分層

表示層: 爲用戶提供接口，使用應用層實現與用戶交互。
應用層: 表示層與領域層的中介，編排業務對象執行特定的應用程序任務，使用應用程序邏輯實現用例。
領域層: 包含業務對象以及業務規則，是應用程序的核心。
基礎設施層: 提供通用的技術功能，支持更高的層，主要使用第三方類庫。

實體(Entity)

一個沒有從其屬性，而是經過連續性和身份的線索來定義的對象。

官方文檔中這句話很是難理解。。。

簡單來講，當一個對象只能由他的標識（Id）來區分，而不是從其餘屬性來區分時，這種對象被稱爲實體。好比有不少叫「張三」的男人，你不能經過姓名和性別來區分究竟是哪一個張三，只能經過Id。實體是能夠持續變化的，咱們能夠對實體進行屢次修改，可是不管怎麼修改，實體始終擁有它惟一的標識。DDD中的實體一般都是充血模型，充血模型就是實體中不光有屬性，還會包含行爲（方法），反之DTO，ViewModel就是典型的貧血模型。實體一般映射到關係型數據庫的表中，ABP中實體相關的基類/接口有：Entity、IEntity、AuditedEntity等等。

值對象(Value Object)

值對象和實體剛好相反，它不須要惟一標識，而且它不能夠被改變。值對象一般是用來度量和描述事物，當你只關注某個對象的屬性時，該對象即可以是一個值對象。好比「北京」就是「北京」，不存在Id=1或者Id=2的北京的說法。固然，值對象雖然不存在惟一標識，可是不表明它在數據庫中就沒有Id主鍵。。。

聚合根(Aggregate Root)

聚合是業務邏輯緊密關聯的實體和值對象組合而成，聚合是數據修改和持久化的基本單元，聚合後產生的根實體稱爲聚合根。若一個聚合僅有一個實體，那這個實體就是聚合根。聚合根被視爲一個單元，你不能單獨去修改聚合根中的子實體。例如，某個業務流程中，會操做A、B、C、D四個對象（簡單理解爲數據庫表），那麼將ABCD聚合，產生一個聚合根E，對外部來講只須要操做E就能夠了，領域內部會處理好ABCD。這樣一方面避免了多個對象的混亂，另外一方面也保證了數據的完整性，不會出現AB操做成功了，CD操做失敗了，致使數據庫產生髒數據。

聚合根引用聚合根：經過ID。

聚合根引用實體：經過對象（導航屬性）。

聚合根引用值對象：經過對象（導航屬性）。

倉儲(Repository)

倉儲用於操做領域對象（實際就是操做數據庫），一般會爲每一個聚合根或不一樣的實體建立對應的倉儲。ABP也提供了通用的泛型倉儲：IRepository<TEntity, TKey>，內置了增刪改查基本功能，直接注入就可使用。

應用服務(Application Services)

應用層處於展現層與領域層之間，展現層一般調用應用服務，應用服務調用領域而後返回數據給展現層。展現層也能夠直接調用領域。APB中應用服務相關的基類/接口有：IApplicationService、ApplicationService、ICrudAppService、CrudAppService等等。

數據傳輸對象(DTO)

一般領域對象不適合直接在應用層與展現層之間傳遞，好比User中的Passwod字段，這時候就須要用到DTO，DTO和ViewModel相似。ABP提供了一些DTO基類/接口：IEntityDto、EntityDto、AuditedEntityDto等等。

工做單元(Unit Of Work)

UOW模式是爲了保證一次業務操做的數據完整性。ABP框架的UOW實現提供了對應用程序中的數據庫鏈接和事務範圍的抽象和控制，使用ABP的話一般你不用本身去寫數據庫事務相關代碼。實際上工做單元不必定非要建立數據庫事務，好比HTTP GET請求就不會啓動事務性UOW，它們仍然啓動UOW，但不建立數據庫事務。這一切都由ABP框架自動完成。