在我較早的時候，就開始研究和介紹ABP框架，ABP框架相對一些其他的框架，它整合了很多.net core的新技術和相關應用場景，雖然最早開始ABP框架是基於.net framework，後來也全部轉向擁抱.net core，而另一條線的ABP VNext則是定位從.net core開始的，基礎類庫以Volo.Abp開始。ABP框架和ABP VNext框架兩者在基類和分層上，都很多幾乎是一樣的，不過ABP VNext框架是後來者，規避了很多前輩ABP框架的一些缺點，最明顯的就是更加模組化（弊端就是管理的獨立專案暴增），不過對於大專案來說，功能模組的切分也是必要的。ABP VNext是一個內容很豐富的架構體系，因此準備做一個系列介紹ABP VNext相關架構的知識，本篇隨筆介紹它的一些框架基礎類繼承關係。

在我較早的時候，就開始研究和介紹ABP框架，ABP框架相對一些其他的框架，它整合了很多.net core的新技術和相關應用場景，雖然最早開始ABP框架是基於.net framework，後來也全部轉向擁抱.net core，而另一條線的ABP VNext則是定位從.net core開始的，基礎類庫以Volo.Abp開始。ABP框架和ABP VNext框架兩者在基類和分層上，都很多幾乎是一樣的，不過ABP VNext框架是後來者，規避了很多前輩ABP框架的一些缺點，最明顯的就是更加模組化（弊端就是管理的獨立專案暴增），不過對於大專案來說，功能模組的切分也是必要的。ABP VNext是一個內容很豐富的架構體系，因此準備做一個系列介紹ABP VNext相關架構的知識，本篇隨筆介紹它的一些框架基礎類繼承關係。

1、ABP VNext技術概述

ABP VNext框架如果不考慮在微服務上的應用，其整合使用的難度會降低一個層級，不過ABP VNext和ABP框架一樣，基礎內容都會設計很多內容，如資料庫都支援Oracle、SQLServer、MySql、PostgreSQL、SQLite，都有利用Redis作為分散式快取，使用RabbitMQ作為事件匯流排的訊息處理方式，使用MongoDB的NoSQL型別資料庫作為特殊資料的儲存服務，使用Quartz/HangFire作為定時任務的處理等。如果考慮引入微服務的話，會更需要了解IdentityServer服務，以及瞭解Ocelot庫管理閘道器，使用Elasticsearch

&Kibana來儲存和視覺化日誌 (使用Serilog寫日誌)，有時候感覺引入框架並非一件輕鬆的事情，各種知識點一股腦的湧來。

我們開發複雜的系統，也是和建築工人一樣，一步步蓋起房子來的，不同的是，有些人一塊磚一塊磚的蓋，有些人採用預構件來構建，我們回到孩童的時候的思路，就是搭建積木的方式。

ABP VNext框架沿襲這種好習慣，把一些都簡單化了，做起大專案來就更加方便了，類似搞一個樂高積木專案一樣，不過我們約定了每個專案的基礎分層部分，這樣一來組裝就標準化了。

如下面的一個專案，也可以當成它就是一個模組，和一個麻雀一樣，五臟俱全，各個專案代表不同的功能，大家都這樣做即可。

應用服務層：

Application.Contracts，包含應用服務介面和相關的資料傳輸物件(DTO)。
Application，包含應用服務實現，依賴於 Domain 包和 Application.Contracts 包。

領域層：
Domain.Shared，包含常量,列舉和其他型別.
Domain 包含實體， 倉儲介面,領域服務介面及其實現和其他領域物件，依賴於 Domain.Shared 包.

基礎設施層：

EntityFrameworkCore，包含EF的ORM處理，使用倉儲模式，實現資料的儲存功能。

HTTP 層
HttpApi專案, 為模組開發REST風格的HTTP API。
HttpApi.Client專案，它將應用服務介面實現遠端端點的客戶端呼叫，提供的動態代理HTTP C＃客戶端的功能。

各個層的依賴關係如下圖所示。

我們把這些專案組成一個模組，即使這個模組只有一個表的處理功能，也是一個模組，它們構建成一個完整的模組內部生態層。

這樣我們在以模組為基礎單位，就可以單獨開發，統一整合了，如下圖所示。

這樣，我們以相關的模組組合，以及一些輔助工具，就構成了整套框架的一個生態基礎。

針對ABP VNext的前後端完全分離模式，我們給BS的前端，只需要提供API服務，以及接入詳細說明即可，而給Winform、WPF、Console等基於.net的終端，則可以利用HTTP層的HttpApi.Client專案的動態客戶端方式，避免編寫API的客戶端代理即可。

我詳細參考了ABP VNext的基礎框架類，以及一些應用模組專案的程式碼，它們基本上是提供了很多底層的支援，上層模組的支援，很多是在其商業版中的功能，並沒有出現在應用模組中，如我們常見的許可權系統的實現，它模組裡面只是提供了簡單的的角色和使用者資訊管理（而且很不完善），而我們往往需要擴充套件開來實現詳細的使用者、組織機構、角色、崗位、選單、許可權等功能的管理，才能算是一個完整的許可權系統，另外還需要封裝字典模組、附件管理模組等一些基礎模組應用，這些就需要我們自己實現它的功能了。

以許可權管理模組為例，它們雖然提供及基礎的DTO和領域物件，沒有提供完整應用層的實現，作為一個完整的應用系統，肯定不行，需要利用框架進一步實現才可以整合在專案中使用。

2、框架基礎類繼承關係

前面介紹了，本篇隨筆作為系列的開篇，主要想介紹一下ABP VNext框架的一些基礎類關係。

ABP VNext和ABP框架的基礎類，雖然它們在專案管理上有所不同，不過它們的類關係層次繼承關係，幾乎沒有太多的變化，有些一些層次上的調整而已。因此對於學習ABP或者ABP VNext框架來說，它們很多地方是共通的。

對於Application層來說，它是承接UI和領域層的中間層，因此它接收使用者DTO物件，並且這些DTO物件為了和領域層的Entity層有對映關係，我們定義了一些基礎類關係來協助它們，以方便DTO和Entity層之間的Mapping對映關係，從而通過約定方式承載系統的基礎屬性。

如ApplicationService層的相關DTO基類物件定義及繼承關係如下圖所示，其中右邊是它們繼承的介面，以及介面需要實現的屬性資訊。

注：上圖ABP和ABP VNext框架，它們的基類定義和關係都是一樣的。

而應用層有時候，需要對資料進行分頁，並返回列表記錄，那麼下面的一些基類物件就是它的應用場景，通過定義分頁資訊和排序資訊，可以讓應用服務層獲得相應的記錄過濾，然後返回基於特定DTO物件的泛型列表，如下圖所示。

注：上圖ABP和ABP VNext框架，它們的基類定義和關係都是一樣的。

ABP VNext框架的應用服務層類，提供了相關CRUD操作的基類，雖然我們有時候可以繼承頂層ApplicationService進行開發，但是，為了方便，我們往往使用子類繼承自CrudAppService，如下圖所示。

首先定義相關自定義介面

public interface IBookAppService : 
    ICrudAppService< //定義CRUD方法
        BookDto, //顯示DTO
        Guid, //實體主鍵
        PagedAndSortedResultRequestDto, //用於分頁排序獲取列表
        CreateUpdateBookDto, //建立物件DTO
        CreateUpdateBookDto> //更新物件DTO
{
}

然後實現該介面即可，如下所示。

public class BookAppService : 
    CrudAppService<Book, BookDto, Guid, PagedAndSortedResultRequestDto,CreateUpdateBookDto, CreateUpdateBookDto>,
    IBookAppService
{
    public BookAppService(IRepository<Book, Guid> repository) 
        : base(repository)
    {
    }
}

CrudAppService實現了ICrudAppService介面中宣告的所有方法. 然後,你可以新增自己的自定義方法或覆蓋和自定義實現.

相對於ABP VNext的應用服務層基類，它們ABP框架的基類有所差異 ，它們分離了同步和非同步的基類，不過基本上都使用非同步基類居多，繼承關係圖如下所示。

、

它的服務層介面定義和介面實現的處理方式和ABP VNext的操作類似，就不再贅述了。

相對於前面介紹DTO層的基類定義，我們在框架的領域層也定義了類似的類和它的繼承關係，和DTO一一對應，這樣通過AutoMapping 的方式就可以自動處理他們的屬性映射了，減少了很多繁瑣的程式碼處理。

領域層的實體類關係和前面DTO關係類似，如下所示。

"聚合是域驅動設計中的一種模式.DDD的聚合是一組可以作為一個單元處理的域物件.例如,訂單及訂單系列的商品,這些是獨立的物件,但將訂單(連同訂單系列的商品)視為一個聚合通常是很有用的。

如果是聚合根，如商品、訂單和訂單明細的關係場景，就可以應用到，ABP不強制你使用聚合根,實際上你可以使用上面定義的Entity類。

它們和領域的實體關係整合起來是一張關係圖，如下所示。

這個在基類部分，和ABP框架有所差異，ABP VNext框架中的聚合根增加了擴充套件屬性的介面定義和實現，以及領域事件的處理介面，如下所示。

它們的部分基類程式碼如下所示

namespace Volo.Abp.Domain.Entities
{
    [Serializable]
    public abstract class AggregateRoot : BasicAggregateRoot,
        IHasExtraProperties,
        IHasConcurrencyStamp
    {
        public virtual ExtraPropertyDictionary ExtraProperties { get; protected set; }

        [DisableAuditing]
        public virtual string ConcurrencyStamp { get; set; }

        protected AggregateRoot()
        {
            ConcurrencyStamp = Guid.NewGuid().ToString("N");
            ExtraProperties = new ExtraPropertyDictionary();
            this.SetDefaultsForExtraProperties();
        }

        public virtual IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
        {
            return ExtensibleObjectValidator.GetValidationErrors(
                this,
                validationContext
            );
        }
    }

而ABP 框架的聚合根部分，除了基類有所差異，處理一些特殊的資訊外，基本上也是類似的。

以上就是ABP VNext的一些基類和關係圖，希望能夠促進我們瞭解ABP VNext框架的神祕之處，解開它的面紗。

如果你對ABP框架的知識點有興趣，可以參考《ABP框架使用》，如果對於ABP框架VUE&Element前端開發有興趣，可以參考《循序漸進VUE+Element》部分內容。

主要研究技術：程式碼生成工具、會員管理系統、客戶關係管理軟體、病人資料管理軟體、Visio二次開發、酒店管理系統、倉庫管理系統等共享軟體開發
專注於Winform開發框架/混合式開發框架、Web開發框架、Bootstrap開發框架、微信門戶開發框架的研究及應用。
  轉載請註明出處：
撰寫人：伍華聰  http://www.iqidi.com