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;
        }

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

    }

因為這些通用的倉儲物件介面已經很多，常規都是夠用的，而不需要進行特定倉儲物件的自定義封裝處理，否則徒增煩惱，

轉載請註明出處，本文鏈接：https://www.uj5u.com/net/41.html

標籤：.NET Core

上一篇：【Azure DevOps系列】Azure DevOps生成代碼覆寫率

下一篇：基于 abp vNext 的快速開發模板