目录结构

本篇介绍解决方案模板的目录结构。

docs

用来分类存放项目相关的文档资料，如需求背景，架构设计，模块设计，技术实现方案等。

scripts

用来存放常用的脚本文件，主要是ps1或cs脚本，减少重复工作量。

src

src是源代码目录，包含解决方案的所有源代码文件，按照功能划分为不同的子目录：

Perigon基础库

提供开发需要的基础类库，全部以源代码形式提供，方便开发者根据需要进行修改和扩展，包含以下项目：

• Perigon.AspNetCore：Web开发相关公共部分，包含基础模型定义，常用扩展方法和工具帮助类等。
• Perigon.AspNetCore.Toolkit：在Web开发中常用的三方类库集成，如发邮件，图形验证码，Excel导出等
• Perigon.AspNetCore.SourceGeneration：源代码生成器和代码分析器相关功能。

由于框架层与项目和业务无关，它们可以被打包成类库，你可以据此开发自己的工具包，发布到私有或公共的Nuget源上，供其他项目使用。

Definition

定义层，定义业务模型，决定了业务的数据模型和行为，是业务实现的基础和前提，通常包括：

• Entity:实体定义，决定核心业务模型的存储结构。
• EntityFramework：ORM映射定义，决定实体与数据库表的映射关系。
• Share：共享常量，DTO，语言服务，默认实现等。
• ServiceDefaults：通用服务注入的定义，如健康检查，重试机制，日志等。

Modules

Module是实现层的载体，主要是实现业务逻辑，通过拆解成不同的Module来实现。

在实际需要中，业务需求常常涉及多个领域或多个业务模块，我们可以按照业务模块进行拆分，框架默认提供CommonMod共享模块，被其他模块引用。

典型结构如下:

• CommonMod：共享模块，供各个业务模块使用。
• CustomerModule：客户模块，包含客户相关的业务逻辑。
• OrderModule：订单模块，包含订单相关的业务逻辑。

对于每个模块，通常包含以下内容：

• Models
• Managers
• Services
• ModuleExtensions.cs

Services

服务层是面向实际调用者的，通常我们通过Restful API或Grpc来提供接口的调用。不同的服务通常使用不同的镜像去部署。

对于接口服务，我们需要关注的是:

• 用户请求：请求的解析和验证
• 业务逻辑：通过调用业务层实现业务逻辑，而不直接在服务层去实现。
• 返回结果：响应的格式化和返回

在该层级，模板默认提供了以下服务

• AdminService：为管理后台提供接口服务。
• ApiService：为前端应用提供接口服务。
• MirgrationService：使用EF Core提供数据库迁移服务。

templates

模板文件目录，用来存放自定义代码生成需要的模板。