­

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框架實現（地址//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;
        }

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

    }

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

 

Tags:

VirMach 便宜 VPS

QNews

QNews