目录结构

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

下面的目录说明以 ApiStandard 为主。MiniApi 不包含 AdminService 和默认 Modules，业务代码默认位于 src/Services/ApiService 的 Endpoints/Managers/Models/Services 目录。

docs

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

scripts

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

src

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

Perigon基础库

提供开发需要的基础类库和工具包。核心库与工具包随模板源代码提供；源代码生成器通过 NuGet 包提供，包含以下能力：

• Perigon.AspNetCore：Web开发相关公共部分，包含基础模型定义，常用扩展方法和工具帮助类等。
• Perigon.AspNetCore.Toolkit：在Web开发中常用的三方类库集成，如发邮件、Excel导出等
• Perigon.AspNetCore.SourceGeneration：版本为 1.1.1 的统一源代码生成器和代码分析器 NuGet 包，不再作为 src/Perigon 下的项目复制到新项目中；同时支持 Manager、Module、Localizer 和 Minimal API endpoint group 注册。

由于框架层与项目和业务无关，它们可以被打包成类库；源代码生成器通过包引用在编译期加载。你可以据此开发自己的工具包，发布到私有或公共的 NuGet 源上，供其他项目使用。

Definition

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

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

Modules

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

在实际需要中，业务需求常常涉及多个领域或多个业务模块，我们可以按照业务模块进行拆分。模块通过 Perigon.CLI 或模块包按需安装，空白模板不默认携带业务模块。

典型结构如下:

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

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

• Models： Dto模型
• Managers: 业务逻辑
• Services: 仅用于该模块的服务
• ModuleExtensions.cs：模块的扩展方法，用于注册模块相关的服务。

Services

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

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

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

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

• AdminService：为管理后台提供接口服务。
• ApiService：为前端应用提供接口服务。
• AppHost：ApiStandard 在这里通过 Aspire AddEFMigrations 声明 EF Core 迁移资源；MiniApi 不包含内置迁移资源。

tests

• UnitTest：不引用 AppHost，不启动 Aspire，适合快速单元测试。
• ApiTest：Aspire 集成测试，使用全局钩子启动 AppHost，并通过 Category=Integration 运行。

templates

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