我们在做某件事情的时候，一般需要详细了解它的特点，以及内在的逻辑关系，一旦我们详细了解了整个事物后，就可以通过一些辅助手段来提高我们的做事情的效率了。本篇随笔介绍ABP VNext框架各分层项目的规则，以及结合代码生成工具Database2Sharp来实现项目类代码，项目文件等内容的快速生成。
ABP VNext框架在官方下载项目的时候，会生成一个标准的空白项目框架，本代码工具不是替代这个项目代码生成，而是基于这个基础上进行基于数据表的增量式开发模块的需求（毕竟官方没有针对数据表的项目代码生成），最终所有的子模块可以集成在主模块上，形成一个完整的系统。
1、ABP VNext框架的项目关系
目前框架代码生成包括：应用服务层：Application.Contracts和Application项目，领域层：Domain.Shared和Domain项目，基础设施层：EntityFrameworkCore项目，HTTP 层：HttpApi和HttpApi.Client项目。生成代码集成相关的基类代码，简化项目文件的类代码。
应用服务层：
Application.Contracts，包含应用服务接口和相关的数据传输对象(DTO)。
Application，包含应用服务实现，依赖于 Domain 包和 Application.Contracts 包。
领域层：
Domain.Shared，包含常量,枚举和其他类型.
Domain 包含实体， 仓储接口,领域服务接口及其实现和其他领域对象，依赖于 Domain.Shared 包.
基础设施层：
EntityFrameworkCore，包含EF的ORM处理，使用仓储模式，实现数据的存储功能。
HTTP 层
HttpApi项目, 为模块开发REST风格的HTTP API。
HttpApi.Client项目，它将应用服务接口实现远程端点的客户端调用，提供的动态代理HTTP C＃客户端的功能。
各个层的依赖关系如下图所示。
2、ABP VNext框架各层的项目代码
我在上篇随笔《在ABP VNext框架中对HttpApi模块的控制器进行基类封装》中介绍了为了简化子类一些繁复代码的重复出现，使用自定义基类方式，封装了一些常用的函数，通过泛型参数的方式，可以完美的实现强类型接口的各种处理。
对于ABP VNext个项目的内容，我们继续推演到它的项目组织上来。为了简便，我们以简单的客户表T_Customer表来介绍框架项目的分层和关系。
对于这个额外添加的表，首先我们来看看应用服务层的Application.Contracts项目文件，如下所示。
其中映射DTO放在DTO目录中，而应用服务的接口定义则放在Interface目录中，使用目录的好处是利于查看和管理，特别是在业务表比较多的情况下。
DTO类的定义如下所示。
其中用到了基类对象EntityDto、CreationAuditedEntityDto、AuditEntityDto、FullAuditedEntityDto几个基类DTO对象，具体采用哪个基类DTO，依赖于我们表的包含哪些系统字段。如只包含CreationTime、CreatorId那么就采用CreationAuditedEntityDto，其他的依次类推。
领域层的实体类关系和前面DTO关系类似，如下所示。
这样我们利用代码生成工具生成代码的时候，就需要判断表的系统字段有哪些来使用不同的系统DTO基类了。
而应用服务层的接口定义文件如下所示，它使用了我们前面随笔介绍过的自定义基类或接口。
通过传入泛型类型，我们可以构建强类型化的接口定义。
应用服务层的Application项目包含DTO映射文件和应用服务层接口实现类，如下所示。
其中映射DTO、Domain Entity(领域实体）关系的Automapper文件放在MapProfile文件夹中，而接口实现类文件则放在Service目录中，也是方便管理。
映射类文件，主要定义DTO和Domain Entity(领域实体）关系，如下所示。
这样文件单独定义，在模块中会统一加载整个程序集的映射文件，比较方便。
public class TestProjectApplicationModule : AbpModule { public override void ConfigureServices(ServiceConfigurationContext context) { Configure<AbpAutoMapperOptions>(options => { options.AddMaps<TestProjectApplicationModule>(); }); } }