ABP開發架構的技術點分析（1）

ABP是ASP.NET Boilerplate的簡稱，ABP是一個開源且文檔友好的應用程式架構。ABP不僅僅是一個架構，它還提供了一個最徍實踐的基于領域驅動設計(DDD)的體系結構模型。ABP架構可以說是.net core整合非常多技術點的一個很好的架構，整個涉及到很多非常多方面的知識。我們來大概了解下ABP架構涉及到的内容。

依賴注入，這個部分使用 Castle windsor （依賴注入容器）來實作依賴注入，這個也是我們經常使用IOC來處理的方式；
Repository倉儲模式，已實作了Entity Framework、NHibernate、MangoDB、記憶體資料庫等，倉儲模式可以快速實作對資料接口的調用；
身份驗證與授權管理，可以使用聲明特性的方式對使用者是否登入，或者接口的權限進行驗證，可以通過一個很細粒度的方式，對各個接口的調用權限進行設定；
資料有效性驗證，ABP自動對接口的輸入參數對象進行非空判斷，并且可以根據屬性的申請資訊對屬性的有效性進行校驗；
審計日志記錄，也就是記錄我們對每個接口的調用記錄，以及對記錄的建立、修改、删除人員進行記錄等處理；
Unit Of Work工作單元模式，為應用層和倉儲層的方法自動實作資料庫事務，預設所有應用服務層的接口，都是以工作單元方式運作，即使它們調用了不同的存儲對象處理，都是處于一個事務的邏輯裡面；
異常處理，ABP架構提供了一整套比較完善的流程處理操作，可以很友善的對異常進行進行記錄和傳遞；
日志記錄，我麼可以利用Log4Net進行正常的日志記錄，友善我們跟蹤程式處理資訊和錯誤資訊；
多語言/本地化支援，ABP架構對多語言的處理也是比較友好的，提供了對XML、JSON語言資訊的配置處理；
Auto Mapping自動映射，這個是ABP的很重要的對象隔離概念，通過使用AutoMaper來實作域對象和DTO對象的屬性映射，可以隔離兩者的邏輯關系，但是又能輕松實作屬性資訊的指派；
動态Web API層，利用這個動态處理，可以把Application Service 直接釋出為Web API層，而不需要在累贅的為每個業務對象手工建立一個Web API的控制器，非常友善；
動态JavaScript的AJax代理處理，可以自動建立Javascript 的代理層來更友善使用Web Api，這個在Web層使用。

1、ABP應用架構項目結構

一般我們涉及到的ABP架構，可能解決方案上都會有這些項目。

而這些項目使用了ABP架構的底層架構子產品，使用基礎子產品可以極大簡化應用架構的規模，提高效率，并抽象正常的功能和約定處理，如下所示。

基礎的ABP架構實作（位址https://github.com/aspnetboilerplate/aspnetboilerplate），這個是我們所說的ABP架構的核心實作；

上面提到的在基礎ABP架構基礎上實作處理的ABP應用架構，如下所示。

它主要是分為下面幾個項目分層。

Core領域核心層，領域層就是業務層，是一個項目的核心，所有業務規則都應該在領域層實作。這個項目裡面，除了定義所需的領域實體類外，其實可以定義我們自己的自定義的倉儲對象（類似DAL/IDAL），以及定義自己的業務邏輯層（類似BLL/IBLL），以及基于AutoMapper映射規則等内容。

EntityFrameworkCore 實體架構核心層，這個項目不需要修改太多内容，隻需要在DbContext裡面加入對應領域對象的倉儲對象即可。

Application.Common和Application應用層：應用層提供一些應用服務（Application Services）方法供展現層調用。一個應用服務方法接收一個DTO(資料傳輸對象)作為輸入參數，使用這個輸入參數執行特定的領域層操作，并根據需要可傳回另一個DTO。

Web.Core Web核心層，基于Web或者Web API的核心層，提供了對身份登陸驗證的基礎處理，沒有其他内容。

Web.Core.Host Web API的宿主層，也是動态釋出Web API的核心内容，另外在Web API裡面整合了Swagger，使得我們可以友善對Web API的接口進行調試。

Migrator資料遷移層，這個是一個輔助建立的控制台程式項目，如果基于DB First，我們可以利用它來建立我們項目的初始化資料庫。

2、ABP架構的動态Web API

我們知道，一般我們釋出需要實作Web API的釋出，需要建立對應的Web API控制器類，然後在Web API應用中注冊對應的路由來處理。由于ABP架構的Application Service層已經是無限接近Web API層的定義了，而且本身ABP架構已經抽象劃分了幾個不同的分層，再引入一個類似Application Service層的Web API層，顯得多餘且累贅，是以ABP架構約定了Application Service層繼承接口和命名規則，也是為引入動态Web API做鋪墊的，用一個通用的Host層，統一動态釋出所有的Web API層，減輕了繁複且累贅的Web API 控制器的定義。

使用ABP自帶的例子來說明，例如有如下的接口定義。

public interface ITaskAppService : IApplicationService
{
    GetTasksOutput GetTasks(GetTasksInput input);
    void UpdateTask(UpdateTaskInput input);
    void CreateTask(CreateTaskInput input);
}

然後其使用動态釋出Web API的方式類似如下邏輯所示。

Configuration.Modules.AbpWebApi().DynamicApiControllerBuilder.For<ITaskAppService>("tasksystem/task").Build();

當然這個是對于特定的接口的處理，通用的動态Web API釋出處理，會通過反射獲得對應的接口清單，然後是逐一進行處理的。

我們這裡如果需要詳細追究ABP的動态Web API釋出的規則處理，可以參考ABP的基礎架構部分，了解 DynamicApiControllerBuilder 的處理邏輯即可。

而ABP架構動态釋出Web API，對應的控制器的方法，約定會根據命名規則進行處理，預設一般為Post，規則如下所示：

Get：如果方法名以 \'Get\'開始
Put：如果方法名以 \'Put\' 或 \'Update\' 開始
Delete：如果方法名以 \'Delete\' 或 \'Remove\' 開始
Post：如果方法名以 \'Post\' 、 \'Create\' 或 \'Insert\' 開始.
Patch：如果方法名以 \'Patch\' 開始.
預設以 POST 方式作為 HTTP 動作.

有了動态釋出Web API層，我們就不需要在Web API層中複制一份類似Application Service的定義和實作了，這樣可以省卻很多麻煩事情，減少維護的代碼。

3、依賴注入的倉儲模式

ABP使用并提供正常的依賴注入。可以簡單地注入任何依賴項（例如：IRepository <Authorization.Tasks.Task>）

依賴注入其實也是IOC，實作了接口的控制反轉，可以在程式啟動的時候，統一根據接口加載對應的實作，而使用的時候，我們隻需要知道接口的使用方法即可。現在的Entity Framework 實體架構都是基于IOC實作的了。

我們這裡假設您已經知道依賴注入帶來的好處和大概的處理，依賴注入一般分為構造函數的注入，和屬性注入。讓我們來看看一個具體的依賴注入實作的代碼。

public class TaskAppService : ApplicationService, ITaskAppService
{
    private readonly IRepository<Task> _taskRepository;

    public TaskAppService(IRepository<Task> taskRepository)
    {
        _taskRepository = taskRepository;
    }

    public async Task UpdateTask(UpdateTaskInput input)
    {
        Logger.Info("Updating a task for input: " + input);

        var task = await _taskRepository.FirstOrDefaultAsync(input.TaskId);
        if (task == null)
        {
            throw new UserFriendlyException(L("CouldNotFindTheTaskMessage"));
        }

        ObjectMapper.MapTo(input, task);
    }
}

這裡的_taskRepository 就是倉儲接口的依賴注入，這個具體的實作是在啟動的時候，有IOC容器進行動态的加入。使用的時候我們在各個函數裡面都是調用對應的倉儲接口（而不是實作）來處理資訊的。

屬性注入的做法類似隻是提供了一個Public的屬性定義供動态設定屬性接口。

public class PersonAppService
{
    public ILogger Logger { get; set; }

    private IPersonRepository _personRepository;

    public PersonAppService(IPersonRepository personRepository)
    {
        _personRepository = personRepository;
        Logger = NullLogger.Instance;
    }

    public void CreatePerson(string name, int age)
    {
        Logger.Debug("Inserting a new person to database with name = " + name);
        var person = new Person { Name = name, Age = age };
        _personRepository.Insert(person);
        Logger.Debug("Successfully inserted!");
    }
}

ABP的依賴注入基于 Castle Windsor架構。Castle Windsor最成熟的DI架構之一。還有很多這樣的架構，如Unity，Ninject，StructureMap，Autofac等等。

接口的執行個體初始化，一般我們啟動程式的時候，使用IoC容器進行統一的處理，如下所示。

var container = new WindsorContainer();

container.Register(
        Component.For<IPersonRepository>().ImplementedBy<PersonRepository>().LifestyleTransient(),
        Component.For<IPersonAppService>().ImplementedBy<PersonAppService>().LifestyleTransient()
    );

var personService = container.Resolve<IPersonAppService>();
personService.CreatePerson("John Doe", 32);

而在ABP架構裡面，一般可以通過 IocManager 來根據程式集統一進行接口的執行個體化處理，按照約定注冊程式集。

IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());

Assembly.GetExecutingAssembly()得到一個對包括此代碼的程式集的引用。按照約定，ABP自動注冊所有 Repositories， Domain Services， Application Services， MVC 控制器和Web API控制器。

另外，ABP架構的資料處理采用了EF架構的倉儲模式來處理資料的增删改查等處理，可以實作多種資料庫的相容，而且能夠抽象實作正常資料操作接口，以及提供非常友善的LINQ處理方式。

在ABP中,倉儲類要實作IRepository接口。在ABP基礎子產品中，它的接口定義如下所示。

對于倉儲類，IRepository定義了許多泛型的方法。比如: Select,Insert,Update,Delete方法(CRUD操作)。在大多數的時候,這些方法已足已應付一般實體的需要。

一般我們定義一些對應的DTO以及領域對象，然後依據對應的接口來實作業務對象的倉儲處理。

例如對于字典類型來說，定義的領域對象如下所示。

namespace MyProject.Dictionary
{
    [Table("TB_DictType")]
    public class DictType : FullAuditedEntity<string>
    {
        /// <summary>
        /// 類型名稱
        /// </summary>
        [Required]
        public virtual string Name { get; set; }

        /// <summary>
        /// 字典代碼
        /// </summary>
        public virtual string Code { get; set; }

        /// <summary>
        /// 父ID
        /// </summary>
        public virtual string PID { get; set; }

        /// <summary>
        /// 備注
        /// </summary>
        public virtual string Remark { get; set; }

        /// <summary>
        /// 排序
        /// </summary>
        public virtual string Seq { get; set; }
    }
}

然後在應用層就直接使用通用的倉儲對象接口即可。

/// <summary>
    /// 字典類型應用服務層實作
    /// </summary>
    [AbpAuthorize]
    public class DictTypeAppService : MyAsyncServiceBase<DictType, DictTypeDto, string, DictTypePagedDto, CreateDictTypeDto, DictTypeDto>, IDictTypeAppService
    {
        /// <summary>
        /// 标準的倉儲對象
        /// </summary>
        private readonly IRepository<DictType, string> _repository;

        public DictTypeAppService(IRepository<DictType, string> repository) : base(repository)
        {
            _repository = repository;
        }

        ............

    }

因為這些通用的倉儲對象接口已經很多，正常都是夠用的，而不需要進行特定倉儲對象的自定義封裝處理，否則徒增煩惱。