ASP.NET Core 数据、状态与服务治理依赖注入、EF Core、配置、HTTP 与状态管理权威实践指南【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本指南基于本仓库aspnet-core技能中>var builder WebApplication.CreateBuilder(args); // 注册框架服务 builder.Services.AddControllers(); builder.Services.AddEndpointsApiExplorer(); // 注册业务服务与基础设施服务 builder.Services.AddScopedIOrderService, OrderService(); builder.Services.AddSingletonITimeProvider, SystemTimeProvider(); builder.Services.AddHttpClientIPaymentClient, PaymentClient(); var app builder.Build(); app.Run();当Program.cs开始积累无关关注点时program-and-pipeline.md 建议将功能注册抽取为扩展方法如services.AddFeatureX()保持Program.cs可读并把框架配置靠近宿主、把业务逻辑隔离在宿主之外。2.2 构造函数注入是默认方式默认通过构造函数注入constructor injection把依赖提供给使用方而非属性注入或服务定位器IServiceProvider.GetService。构造函数注入让依赖关系显式可见、便于单元测试替换。2.3 生命周期选择的三个维度服务生命周期必须刻意选择对应 program-and-pipeline.md 的 Service Registration 小节生命周期注册方法适用场景注意事项SingletonAddSingletonT()无状态或共享基础设施如ITimeProvider、缓存服务整个进程共享一个实例ScopedAddScopedT()请求绑定工作如DbContext每个请求作用域一个实例TransientAddTransientT()轻量无状态服务每次解析都新建实例Scoped 服务应保持请求绑定Keep scoped services request-boundscoped 实例的生命周期与当前请求作用域一致不要在长生命周期上下文中使用。避免从单例中解析 scoped 服务Avoid resolving scoped services from singletons单例实例被创建后长期存活若其构造函数依赖 scoped 服务如DbContext则捕获的 scoped 实例会脱离请求作用域造成连接泄漏、过期数据与并发问题——这是 ASP.NET Core 集成测试中最常见的 DI 错误之一。如果单例确实需要在每个请求中获得独立数据上下文应改用工厂模式见第三节的IDbContextFactoryTContext。2.4 Keyed / Named 模式仅在确有多个实现时使用只有当确实存在多个实现需要区分时才使用 keyed键控或 named命名注册模式例如builder.Services.AddKeyedScopedIPaymentGateway, StripeGateway(stripe); builder.Services.AddKeyedScopedIPaymentGateway, PayPalGateway(paypal); // 使用时 public class CheckoutService( [FromKeyedServices(stripe)] IPaymentGateway stripe) { ... }原则是不要为了看起来灵活而引入键控单一实现用默认注册即可过度设计反而增加认知负担。三、EF Core 与 DbContext 的正确用法3.1 默认数据访问层选择文档明确使用 EF Core 处理常见关系型数据访问模式除非仓库已使用其他数据层。默认指导如下用AddDbContext注册DbContext将DbContext视为scoped生命周期把查询与事务放在服务层而非 UI 代码中控制器、页面模型、路由处理器只做编排有意地使用迁移migrations实体类不要进入公共 API 契约与 UI 视图模型。最后一点与 apis-minimal-and-controllers.md 的共享 API 实践完全一致请求/响应 DTO 必须与持久化模型分离避免把 EF 实体直接序列化给客户端导致过度暴露over-posting与契约耦合问题。典型的注册方式var builder WebApplication.CreateBuilder(args); builder.Services.AddDbContextAppDbContext(options options.UseSqlServer( builder.Configuration.GetConnectionString(DefaultConnection)));DbContext默认按请求作用域注册scoped因此在一个请求内多次解析会得到同一实例保证工作单元unit of work内变更跟踪与事务的一致性。查询与事务应当封装在服务中public class OrderService(AppDbContext db) { public async Taskint PlaceOrderAsync(OrderDto dto, CancellationToken ct) { // 事务与查询逻辑在服务层而不是放在控制器/页面模型里 await using var transaction await db.Database.BeginTransactionAsync(ct); try { // ... 业务逻辑 await transaction.CommitAsync(ct); return order.Id; } catch { await transaction.RollbackAsync(ct); throw; } } }迁移migrations用于以受控、可审阅的方式演进数据库架构应纳入版本控制而不是在运行时用EnsureCreated这类方式代替除非是明确的原型场景。3.2 何时改用 IDbContextFactory当执行模型不是请求作用域时使用IDbContextFactoryTContext按需创建短生命周期的DbContext。文档列出的典型场景包括Blazor 组件中的长生命周期作用域Blazor 组件的 scoped 服务存活时间可能远长于单个 HTTP 请求例如交互式服务器端渲染时直接注入DbContext会持有过期的追踪器与连接后台服务Background Services / Hosted ServicesIHostedService是单例注入 scoped 的DbContext属于从单例解析 scoped的典型违规显式工厂驱动的数据工作需要精细控制每个工作单元生命周期的场景。var builder WebApplication.CreateBuilder(args); builder.Services.AddDbContextFactoryAppDbContext(options options.UseSqlServer(builder.Configuration.GetConnectionString(DefaultConnection)));后台服务中按需创建独立上下文public class ReportBackgroundService( IDbContextFactoryAppDbContext contextFactory) : BackgroundService { protected override async Task ExecuteAsync(CancellationToken stoppingToken) { await using var db await contextFactory.CreateDbContextAsync(stoppingToken); // 每个工作单元独立上下文用完即释放 } }DbContextFactory本身可以注册为任意生命周期从而安全地服务于单例后台服务或长生命周期组件Blazor而不会捕获请求绑定的状态。四、Options 与配置治理4.1 将结构化配置绑定到 Options 类规范要求将结构化配置绑定到 options 类而非到处读取散落的配置键。Options 模式把配置变成强类型、可编译期校验的类public class SmtpOptions { public const string SectionName Smtp; public string Host { get; set; } string.Empty; public int Port { get; set; } 587; public bool EnableSsl { get; set; } true; }builder.Services.ConfigureSmtpOptions( builder.Configuration.GetSection(SmtpOptions.SectionName));program-and-pipeline.md 补充说明WebApplication.CreateBuilder已默认从appsettings.json、环境相关的appsettings.{Environment}.json、环境变量与命令行参数等提供程序加载配置因此 Options 绑定可以直接使用合并后的builder.Configuration。4.2 尽早校验快速失败当配置错误应快速失败fail fast时应在启动阶段校验 options而不是等到运行时才爆出晦涩错误builder.Services.AddOptionsSmtpOptions() .Bind(builder.Configuration.GetSection(SmtpOptions.SectionName)) .ValidateDataAnnotations() // 基于 DataAnnotations 校验 .ValidateOnStart(); // 启动时立即校验失败则拒绝启动ValidateOnStart()让应用在进程启动时即校验配置配合在生产环境尽早暴露配置错误的运维保障见 testing-performance-and-operations.md 的 Operational Safeguardsfail fast on invalid configuration可以有效避免带病上线。4.3 配置访问靠近属主服务避免散落原始键配置访问应靠近拥有它的服务每个服务通过自己对应的IOptionsT/IOptionsMonitorT读取配置而不是在 UI 层或跨多个类中直接散布config[Smtp:Host]这种原始键。这样做的好处是配置变更点收敛重命名配置节只需改一处服务可在测试中注入自定义 options使用IOptionsMonitorT时还能感知运行时配置重载。原则总结避免在整个代码库中散落原始配置键avoid scattering raw configuration keys across the codebase。五、出站 HTTP统一使用 IHttpClientFactory5.1 为什么禁用散落的 new HttpClient()文档明确要求出站 HTTP 调用统一使用IHttpClientFactory并避免在请求处理器中散落手动new HttpClient()。原因在于HttpClient的底层 socket 资源若不复用会被频繁释放重建导致端口耗尽socket exhaustion而散落创建的客户端也不利于统一超时、重试与可观测性治理。5.2 三种客户端模式的选型文档给出偏好排序模式适用场景示例Named clients命名客户端对应不同的外部系统各自拥有独立配置AddHttpClient(github, c c.BaseAddress new Uri(https://api.github.com/))Typed clients类型化客户端更丰富的集成客户端封装外部系统 API便于注入与测试AddHttpClientIPaymentClient, PaymentClient()Delegating handlers委托处理程序重试、自定义请求头、遥测等横切关注点AddHttpMessageHandlerRetryHandler()类型化客户端示例builder.Services.AddHttpClientIPaymentClient, PaymentClient(client { client.BaseAddress new Uri(https://pay.example.com); client.Timeout TimeSpan.FromSeconds(30); });委托处理程序用于横切关注点public class TelemetryHandler : DelegatingHandler { protected override async TaskHttpResponseMessage SendAsync( HttpRequestMessage request, CancellationToken cancellationToken) { request.Headers.Add(X-Trace-Id, TraceId); return await base.SendAsync(request, cancellationToken); } } builder.Services.AddTransientTelemetryHandler(); builder.Services.AddHttpClientIPaymentClient, PaymentClient() .AddHttpMessageHandlerTelemetryHandler();命名客户端适合一个外部系统一套策略的朴素场景类型化客户端进一步把 HttpClient 使用细节封装成可注入、可 mock 的服务委托处理程序则把重试、鉴权头注入、指标采集等横切逻辑从业务代码中剥离形成管线化复用。六、应用状态App State选择最小的状态机制6.1 状态机制递进选型文档的核心主张是使用适合场景的最小状态机制Use the smallest state mechanism that fits按以下递进关系选择状态机制适用场景特点Query string / 路由值透明的请求状态可分享、可收藏的 URL 语义无服务端存储天然无状态Form posts用户输入回传承载用户提交的数据TempData短生命周期、面向重定向的消息PRG 模式读取一次后即清除适合操作成功提示Session仅在必要时使用且须理解其服务端存储与扩展性影响服务端存储默认基于 cookie 会话标识典型 PRGPost-Redirect-Get模式中TempData 用于在重定向前暂存一次性提示消息// 控制器或页面模型中 TempData[Message] 订单已提交; // 重定向后 var message TempData[Message] as string;6.2 Session 的边界与警示文档给出两条硬性约束Session 仅在必要时使用且必须理解其服务端存储与横向扩展scaling影响。ASP.NET Core 的 Session 默认把数据存于服务进程内内存并依赖>服务统一在Program.cs或抽取的扩展方法中注册默认构造函数注入scoped 服务保持请求绑定绝不从单例解析DbContext等 scoped 依赖keyed/named 注册仅在有多个实现时使用关系型数据访问默认 EF CoreAddDbContext注册、scoped 生命周期、服务层承载查询与事务实体不进入 API 契约与 UI 视图模型保持 DTO 与持久化模型分离非请求作用域Blazor 长生命周期组件、后台服务使用IDbContextFactoryTContext结构化配置绑定 options 类必要时ValidateOnStart快速失败不散落原始配置键出站 HTTP 统一IHttpClientFactory命名客户端区分外部系统、类型化客户端封装集成、委托处理程序承载重试/头/遥测应用状态按query/route → form → TempData → Session的最小机制递进选择Session 不作为主数据存储缓存数据可从持久源派生缓存形状与持久化形状分离扩展多实例前重新审视 session、内存缓存与单例状态。本指南对应的完整参考文档位于 contenteditable="false">【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考