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.cnblogs.com/wuhuacong/p/13595291.html