Smartstore依赖注入实战：Autofac与Microsoft DI的最佳实践-开发者社区

Smartstore依赖注入实战：Autofac与Microsoft DI的最佳实践

【免费下载链接】SmartstoreA modular, scalable and ultra-fast open-source all-in-one eCommerce platform built on ASP.NET Core 10项目地址: https://gitcode.com/GitHub_Trending/smar/Smartstore

Smartstore是一个基于 ASP.NET Core 10 构建的模块化、可扩展、超高速开源一体化电商平台。它的核心架构深度依赖依赖注入（DI）：以 Microsoft DI 为骨架、Autofac 为增强引擎，实现了干净解耦的服务管理。本文面向新手，用最少的心智负担讲清楚这两套容器如何协作、服务如何注册与解析，以及初学者最容易踩的坑。

为什么 Smartstore 同时使用 Autofac 和 Microsoft DI？

先理解一个基本概念——控制反转（IoC）：不是让类自己去new依赖，而是把依赖在构造时"注入"进来。这样类与类之间解耦，替换实现、单元测试都变得轻松。

Smartstore 的选型思路是：

Microsoft DI：ASP.NET Core 的"原生"容器，简单直接，负责注册 HttpClient、Options、MvcOptions 这类框架级服务；
Autofac：提供更强的能力——适配器、装饰器、注册源、命名/键控注册、自动发现等 Microsoft DI 缺少的特性。

妙处在于：Autofac 内部本身就运行在 Microsoft DI 之上，两套 API 注册的服务最终进入同一个容器，解析时无缝互通。你写模块时既可以选IServiceCollection的简洁语法，也可以用ContainerBuilder的高级玩法，看场景而定。

服务注册三步走：Starter 启动器类

在 Smartstore 中，注册服务的统一入口是继承 StarterBase.cs 的启动器类（约定声明为internal，核心代码放在各模块的Bootstrapping文件夹下）。

它提供两个关键方法，任你选择：

方法	用什么注册	适合场景
`ConfigureServices`	Microsoft 的`IServiceCollection`	HttpClient、Options、Scoped 服务
`ConfigureContainer`	Autofac 的`ContainerBuilder`	命名/键控注册、元数据、装饰器等高级注册

模块开发有一个约定：模块项目根目录下的启动器类命名为Startup，这样所有模块结构统一、代码好找。

三大依赖作用域速查表

这是新手最该记住的一张表，两种 API 完全对应：

ContainerBuilder（Autofac）	IServiceCollection（Microsoft）	效果
`InstancePerDependency`	`AddTransient`	每次解析都拿到全新实例（默认）
`InstancePerLifetimeScope`	`AddScoped`	同一个 HTTP 请求内共享同一实例，跨请求各不相同
`SingleInstance`	`AddSingleton`	全局唯一，永远共享同一实例

另外，Smartstore 还提供了 ServiceLifetimeAttribute.cs：给类打上这个特性，即可通过自动发现按指定生命周期注册，省得手写注册代码。

服务解析的正确姿势

注册只是上半场，如何拿到服务才是决定代码可测试性的关键。

1️⃣ 构造函数注入（首选）

Smartstore 官方推荐的解析方式，要求组件本身已在容器注册。好处是依赖关系一目了然，天然便于单元测试。

2️⃣ 属性注入（ICommonServices）

ICommonServices打包了IWorkContext、StoreContext、SmartDbContext等常用助手。在继承SmartController或SmartViewComponent的控制器里，它被自动属性注入，通过Services成员即可访问，构造函数一个参数都不用写。其他类只有在确实需要多个助手时才手动注入。

3️⃣ Work<T> 延迟解析

有时依赖要等组件构造很久之后才第一次用到（比如容器尚未就绪的启动早期）。Work.cs 就是为此设计的：构造函数里拿到的是一个"占位符"，真正访问Value属性时才从当前ILifetimeScope解析出服务。适合在循环中偶尔才需要的服务，避免不必要的实例化。

4️⃣ 自定义作用域（ILifetimeScopeAccessor）

ScopedServiceContainer.cs 封装了请求级容器的各种解析方法（含ResolveKeyed、ResolveNamed、TryResolve等）。而 ILifetimeScopeAccessor.cs 则允许你在请求管道之外（后台任务、CLI 工具）创建作用域，甚至像数据导入器那样为每个批次开一个"子作用域"，批次处理完自动释放内存。

⚠️两条红线：

永远不要从IApplicationContext.Services（根容器）解析 Scoped 依赖，那里只能拿单例，否则会造成内存泄漏；
尽量避免通过EngineContext.Current.Scope全局静态解析，会让单元测试几乎无法进行。

新手必看的 4 条最佳实践清单

注册统一走 Starter：所有注册集中在ConfigureServices/ConfigureContainer中完成，不要散落在业务代码里；
只注入你真正需要的依赖：避免依赖ICommonServices这种"大管家"式组件（它主要为控制器设计），注入的依赖越多，单元测试越痛苦；
覆盖服务用"后注册优先"：在ConfigureServices里对同一接口再注册一次新实现即可覆盖（last registration wins），这是模块替换核心行为的标准手法；
属性注入慎用：仅限特殊场景（抽象类）或极简单的服务（如Logger、Localizer），构造函数注入永远是第一选择。