为什么你的 .NET Minimal API 越来越乱Clean Minimal API 用 FastEndpoints 给出优雅答案【免费下载链接】clean-minimal-apiA project showcasing how you can build a clean Minimal API using FastEndpoints项目地址: https://gitcode.com/gh_mirrors/cl/clean-minimal-apiClean Minimal API是一个基于FastEndpoints构建的 .NET Minimal API 最佳实践示例项目它用一个客户管理系统Customer CRUD演示了如何把写着写着就变乱的最小 API演进为结构清晰、易于维护、自带文档的干净 API。如果你正被 .NET Minimal API 膨胀的代码折磨这篇指南将带你读懂它的分层设计思路。Minimal API 常见的 4 种变乱症状 Minimal API 最大的优点是轻但代码量一上来就容易失控端点堆成一座山所有app.MapPost(...)挤在Program.cs几百行代码找不到北校验散落各处if/else 判断请求参数漏一个字段就是线上事故业务逻辑混在路由里改一个字段要同时动路由、DTO、SQL牵一发动全身没有接口文档前后端对接口只能靠口口相传。Clean Minimal API 针对这 4 个痛点给出了一套可以直接照抄的解法。项目架构一个文件夹一种职责 整个 API 位于 Customers.Api/ 目录每个文件夹只干一件事目录职责解决的问题Endpoints/路由端点每个接口一个类端点不再堆在一起Services/业务逻辑如 CustomerService.cs业务与路由解耦Repositories/数据访问CustomerRepository.cs 基于 Dapper换数据库不动业务Domain/领域模型与值对象数据自带校验规则Contracts/请求/响应契约入参出参类型安全Validation/FluentValidation 校验器校验集中、可复用Mapping/各层之间的对象映射转换逻辑不散落Summaries/接口摘要与响应码说明Swagger 文档自动生成这种按职责切分的目录结构就是 Clean Minimal API 的核心思想——Minimal API 依然很轻但轻的是依赖不是秩序。FastEndpoints把混乱变有序的 3 个关键能力 ⚡Program.cs 中只需两行核心注册整个 API 框架就跑起来了builder.Services.AddFastEndpoints(); builder.Services.AddSwaggerDoc();FastEndpoints 带来的能力正好对症上面的 4 个症状1️⃣ 一个端点 一个类路由即代码创建客户接口 CreateCustomerEndpoint.cs 只有 30 行左右[HttpPost(customers), AllowAnonymous] public class CreateCustomerEndpoint : EndpointCreateCustomerRequest, CustomerResponse { public override async Task HandleAsync(CreateCustomerRequest req, CancellationToken ct) { var customer req.ToCustomer(); await _customerService.CreateAsync(customer); // ... } }路由用特性声明入参出参用泛型约束依赖通过构造函数注入——每个接口独立成文件增删改查一目了然共 5 个端点Create/Get/GetAll/Update/Delete。2️⃣ 校验交给 FluentValidation错误统一格式CreateCustomerRequestValidator.cs 等校验器独立存放而 ValidationExceptionMiddleware.cs 作为中间件兜底把任何校验异常统一转成 400 结构化错误响应前后端对接零摩擦。3️⃣ Swagger 文档几乎零成本每个端点配一个 Summary如 CreateCustomerSummary.cs描述接口用途和各状态码含义配合 Program.cs 中的app.UseSwaggerUi3(...)启动后直接在浏览器里打开 Swagger UI 调试接口文档永远和代码同步。领域建模让数据自己把关 更值得学习的是Domain/Common/下的值对象设计——以 EmailAddress.cs 为例邮箱格式的正则校验直接内嵌在类型里任何地方只要用到EmailAddress类型非法值会在构造瞬间被拦截而不是等到接口层才发现。CustomerId、Username、FullName、DateOfBirth都是同一套路配合 Customer.cs 组成完整的领域模型。快速上手3 步跑通完整示例 git clone https://gitcode.com/gh_mirrors/cl/clean-minimal-api cd clean-minimal-api/Customers.Api dotnet run启动后打开 Swagger UI 即可浏览全部 5 个客户接口想手动试接口structured.http 里已备好 GET/POST/PUT/DELETE 全套请求模板VS 里直接发数据库使用 SQLiteDatabaseInitializer.cs 会自动初始化表结构零配置。总结Clean Minimal API 教会我们的 3 件事 ✅FastEndpoints让 Minimal API 摆脱面条代码端点类化、契约泛型化、文档自动化按职责分层Endpoint → Service → Repository比一个文件搞定一切更容易维护值对象 FluentValidation双保险把校验逻辑从 if/else 地狱中解放出来。项目很小但五脏俱全——把它当作 .NET Minimal API 从能跑走向干净的模板照着搭你下一个 API 吧。【免费下载链接】clean-minimal-apiA project showcasing how you can build a clean Minimal API using FastEndpoints项目地址: https://gitcode.com/gh_mirrors/cl/clean-minimal-api创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为什么你的 .NET Minimal API 越来越乱？Clean Minimal API 用 FastEndpoints 给出优雅答案
为什么你的 .NET Minimal API 越来越乱Clean Minimal API 用 FastEndpoints 给出优雅答案【免费下载链接】clean-minimal-apiA project showcasing how you can build a clean Minimal API using FastEndpoints项目地址: https://gitcode.com/gh_mirrors/cl/clean-minimal-apiClean Minimal API是一个基于FastEndpoints构建的 .NET Minimal API 最佳实践示例项目它用一个客户管理系统Customer CRUD演示了如何把写着写着就变乱的最小 API演进为结构清晰、易于维护、自带文档的干净 API。如果你正被 .NET Minimal API 膨胀的代码折磨这篇指南将带你读懂它的分层设计思路。Minimal API 常见的 4 种变乱症状 Minimal API 最大的优点是轻但代码量一上来就容易失控端点堆成一座山所有app.MapPost(...)挤在Program.cs几百行代码找不到北校验散落各处if/else 判断请求参数漏一个字段就是线上事故业务逻辑混在路由里改一个字段要同时动路由、DTO、SQL牵一发动全身没有接口文档前后端对接口只能靠口口相传。Clean Minimal API 针对这 4 个痛点给出了一套可以直接照抄的解法。项目架构一个文件夹一种职责 整个 API 位于 Customers.Api/ 目录每个文件夹只干一件事目录职责解决的问题Endpoints/路由端点每个接口一个类端点不再堆在一起Services/业务逻辑如 CustomerService.cs业务与路由解耦Repositories/数据访问CustomerRepository.cs 基于 Dapper换数据库不动业务Domain/领域模型与值对象数据自带校验规则Contracts/请求/响应契约入参出参类型安全Validation/FluentValidation 校验器校验集中、可复用Mapping/各层之间的对象映射转换逻辑不散落Summaries/接口摘要与响应码说明Swagger 文档自动生成这种按职责切分的目录结构就是 Clean Minimal API 的核心思想——Minimal API 依然很轻但轻的是依赖不是秩序。FastEndpoints把混乱变有序的 3 个关键能力 ⚡Program.cs 中只需两行核心注册整个 API 框架就跑起来了builder.Services.AddFastEndpoints(); builder.Services.AddSwaggerDoc();FastEndpoints 带来的能力正好对症上面的 4 个症状1️⃣ 一个端点 一个类路由即代码创建客户接口 CreateCustomerEndpoint.cs 只有 30 行左右[HttpPost(customers), AllowAnonymous] public class CreateCustomerEndpoint : EndpointCreateCustomerRequest, CustomerResponse { public override async Task HandleAsync(CreateCustomerRequest req, CancellationToken ct) { var customer req.ToCustomer(); await _customerService.CreateAsync(customer); // ... } }路由用特性声明入参出参用泛型约束依赖通过构造函数注入——每个接口独立成文件增删改查一目了然共 5 个端点Create/Get/GetAll/Update/Delete。2️⃣ 校验交给 FluentValidation错误统一格式CreateCustomerRequestValidator.cs 等校验器独立存放而 ValidationExceptionMiddleware.cs 作为中间件兜底把任何校验异常统一转成 400 结构化错误响应前后端对接零摩擦。3️⃣ Swagger 文档几乎零成本每个端点配一个 Summary如 CreateCustomerSummary.cs描述接口用途和各状态码含义配合 Program.cs 中的app.UseSwaggerUi3(...)启动后直接在浏览器里打开 Swagger UI 调试接口文档永远和代码同步。领域建模让数据自己把关 更值得学习的是Domain/Common/下的值对象设计——以 EmailAddress.cs 为例邮箱格式的正则校验直接内嵌在类型里任何地方只要用到EmailAddress类型非法值会在构造瞬间被拦截而不是等到接口层才发现。CustomerId、Username、FullName、DateOfBirth都是同一套路配合 Customer.cs 组成完整的领域模型。快速上手3 步跑通完整示例 git clone https://gitcode.com/gh_mirrors/cl/clean-minimal-api cd clean-minimal-api/Customers.Api dotnet run启动后打开 Swagger UI 即可浏览全部 5 个客户接口想手动试接口structured.http 里已备好 GET/POST/PUT/DELETE 全套请求模板VS 里直接发数据库使用 SQLiteDatabaseInitializer.cs 会自动初始化表结构零配置。总结Clean Minimal API 教会我们的 3 件事 ✅FastEndpoints让 Minimal API 摆脱面条代码端点类化、契约泛型化、文档自动化按职责分层Endpoint → Service → Repository比一个文件搞定一切更容易维护值对象 FluentValidation双保险把校验逻辑从 if/else 地狱中解放出来。项目很小但五脏俱全——把它当作 .NET Minimal API 从能跑走向干净的模板照着搭你下一个 API 吧。【免费下载链接】clean-minimal-apiA project showcasing how you can build a clean Minimal API using FastEndpoints项目地址: https://gitcode.com/gh_mirrors/cl/clean-minimal-api创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考