剩余的 IValidationEnabled、IUnitOfWorkEnabled、IAuditingEnabled、ITransientDependency 接口类似于一个启用标识，只要类型继承了该接口，就会执行一些特殊的操作。
回到之前的简单基类里面，ABP vNext 为我们注入了大量基础设施，例如获取当前用户的 ICurrentUser 组件，获取当前租户的 ICurrentTenant 组件，还有日志组件等。
除了基础组件，ABP vNext 在简单基类里面还提供了一个权限检测方法，用户检测当前用户是否具备某些权限。
protected virtual async Task CheckPolicyAsync([CanBeNull] string policyName) { if (string.IsNullOrEmpty(policyName)) { return; } await AuthorizationService.CheckAsync(policyName); }在不具备权限的时候，ABP vNext 会抛出 AbpAuthorizationException 异常。
2.2.2 Crud 基类Crud 基类可以极大减少对于某些简单对象的代码编写，例如我有个客户管理接口，只需要简单地增删改查操作。那么我就可以直接继承自 Crud 基类，给它填写和是的泛型参数之后，ABP vNext 就会为我们生成带有增删改查操作的应用服务对象。
这个 Crud 基类拥有多个泛型定义与实现，除了真正的实现以外，其他的都是简单的调用基类方法而已。我们直接进入主题，看一下类型签名为 public abstract class CrudAppService<TEntity, TGetOutputDto, TGetListOutputDto, TKey, TGetListInput, TCreateInput, TUpdateInput> 的基类。
public abstract class CrudAppService<TEntity, TGetOutputDto, TGetListOutputDto, TKey, TGetListInput, TCreateInput, TUpdateInput> : ApplicationService, ICrudAppService<TGetOutputDto, TGetListOutputDto, TKey, TGetListInput, TCreateInput, TUpdateInput> where TEntity : class, IEntity<TKey> where TGetOutputDto : IEntityDto<TKey> where TGetListOutputDto : IEntityDto<TKey> { public virtual async Task<TGetOutputDto> GetAsync(TKey id) { // 具体代码。 } public virtual async Task<PagedResultDto<TGetListOutputDto>> GetListAsync(TGetListInput input) { // 具体代码。 } public virtual async Task<TGetOutputDto> CreateAsync(TCreateInput input) { // 具体代码。 } public virtual async Task<TGetOutputDto> UpdateAsync(TKey id, TUpdateInput input) { // 具体代码。 } public virtual async Task DeleteAsync(TKey id) { // 具体代码。 } }从上述代码可以看到基类根据传入的泛型参数，将会为我们实现常规的增删改查逻辑。我们也可以随时重写这些方法，来达到一些个性化的操作。
ABP vNext 抽象了公用接口以外，在内部还编写了诸如 MapToEntity() 和 MapToEntity() 等内部共用方法，这里就不再详细赘述，这些方法都是 protected 修饰的，你也可以随时重写来达到自己的目的。
2.3 数据传输对象一般来说，应用服务层返回给展示层的数据肯定是某个实体对象的部分属性，或者是多个聚合的整体，这个时候就需要 DTO 来帮我们处理应用服务层与外部的数据交换了。
ABP vNext 在应用服务模块定义了常用的一些 DTO 对象，例如实体 DTO 和分页查询 DTO，关于这些 DTO 你只需将其看作一个数据容器即可，不需要太多关注，这里也没有太多要讲的。
三、总结ABP vNext 提供的应用服务层模块还是比较简单的，里面主要是针对应用服务基类进行了预定义。方便我们开发人员进行业务开发，而不需要自己实现这些繁杂的基类。
在 DDD 当中，应用服务是表达 用户用例 和 用户故事 的主要手段，应用服务只是通过领域对象/领域服务来表达需求用例的一个组件。不要将业务逻辑泄漏到应用服务当中，这种设计最终会导致贫血领域模型。
四、点击我跳转到文章目录