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 interfaceITaskAppService : IApplicationService
{
GetTasksOutput GetTasks(GetTasksInput input);voidUpdateTask(UpdateTaskInput input);voidCreateTask(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 classTaskAppService : ApplicationService, ITaskAppService
{private readonly IRepository<Task>_taskRepository;public TaskAppService(IRepository<Task>taskRepository)
{
_taskRepository=taskRepository;
}public asyncTask 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 classPersonAppService
{public ILogger Logger { get; set; }privateIPersonRepository _personRepository;publicPersonAppService(IPersonRepository personRepository)
{
_personRepository=personRepository;
Logger=NullLogger.Instance;
}public void CreatePerson(string name, intage)
{
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 = newWindsorContainer();
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以及领域对象，然后依据对应的接口来实现业务对象的仓储处理。
例如对于字典类型来说，定义的领域对象如下所示。
namespaceMyProject.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;
}
............
}
因为这些通用的仓储对象接口已经很多，常规都是够用的，而不需要进行特定仓储对象的自定义封装处理，否则徒增烦恼。
