ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

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/SmartstoreSmartstore是一个基于 ASP.NET Core 10 构建的模块化、可扩展、超高速开源一体化电商平台。它的核心架构深度依赖依赖注入DI以 Microsoft DI 为骨架、Autofac 为增强引擎实现了干净解耦的服务管理。本文面向新手用最少的心智负担讲清楚这两套容器如何协作、服务如何注册与解析以及初学者最容易踩的坑。为什么 Smartstore 同时使用 Autofac 和 Microsoft DI先理解一个基本概念——控制反转IoC不是让类自己去new依赖而是把依赖在构造时注入进来。这样类与类之间解耦替换实现、单元测试都变得轻松。Smartstore 的选型思路是Microsoft DIASP.NET Core 的原生容器简单直接负责注册 HttpClient、Options、MvcOptions 这类框架级服务Autofac提供更强的能力——适配器、装饰器、注册源、命名/键控注册、自动发现等 Microsoft DI 缺少的特性。妙处在于Autofac 内部本身就运行在 Microsoft DI 之上两套 API 注册的服务最终进入同一个容器解析时无缝互通。你写模块时既可以选IServiceCollection的简洁语法也可以用ContainerBuilder的高级玩法看场景而定。服务注册三步走Starter 启动器类在 Smartstore 中注册服务的统一入口是继承 StarterBase.cs 的启动器类约定声明为internal核心代码放在各模块的Bootstrapping文件夹下。它提供两个关键方法任你选择方法用什么注册适合场景ConfigureServicesMicrosoft 的IServiceCollectionHttpClient、Options、Scoped 服务ConfigureContainerAutofac 的ContainerBuilder命名/键控注册、元数据、装饰器等高级注册模块开发有一个约定模块项目根目录下的启动器类命名为Startup这样所有模块结构统一、代码好找。三大依赖作用域速查表这是新手最该记住的一张表两种 API 完全对应ContainerBuilderAutofacIServiceCollectionMicrosoft效果InstancePerDependencyAddTransient每次解析都拿到全新实例默认InstancePerLifetimeScopeAddScoped同一个 HTTP 请求内共享同一实例跨请求各不相同SingleInstanceAddSingleton全局唯一永远共享同一实例另外Smartstore 还提供了 ServiceLifetimeAttribute.cs给类打上这个特性即可通过自动发现按指定生命周期注册省得手写注册代码。服务解析的正确姿势注册只是上半场如何拿到服务才是决定代码可测试性的关键。1️⃣ 构造函数注入首选Smartstore 官方推荐的解析方式要求组件本身已在容器注册。好处是依赖关系一目了然天然便于单元测试。2️⃣ 属性注入ICommonServicesICommonServices打包了IWorkContext、StoreContext、SmartDbContext等常用助手。在继承SmartController或SmartViewComponent的控制器里它被自动属性注入通过Services成员即可访问构造函数一个参数都不用写。其他类只有在确实需要多个助手时才手动注入。3️⃣ WorkT 延迟解析有时依赖要等组件构造很久之后才第一次用到比如容器尚未就绪的启动早期。Work.cs 就是为此设计的构造函数里拿到的是一个占位符真正访问Value属性时才从当前ILifetimeScope解析出服务。适合在循环中偶尔才需要的服务避免不必要的实例化。4️⃣ 自定义作用域ILifetimeScopeAccessorScopedServiceContainer.cs 封装了请求级容器的各种解析方法含ResolveKeyed、ResolveNamed、TryResolve等。而 ILifetimeScopeAccessor.cs 则允许你在请求管道之外后台任务、CLI 工具创建作用域甚至像数据导入器那样为每个批次开一个子作用域批次处理完自动释放内存。⚠️两条红线永远不要从IApplicationContext.Services根容器解析 Scoped 依赖那里只能拿单例否则会造成内存泄漏尽量避免通过EngineContext.Current.Scope全局静态解析会让单元测试几乎无法进行。新手必看的 4 条最佳实践清单注册统一走 Starter所有注册集中在ConfigureServices/ConfigureContainer中完成不要散落在业务代码里只注入你真正需要的依赖避免依赖ICommonServices这种大管家式组件它主要为控制器设计注入的依赖越多单元测试越痛苦覆盖服务用后注册优先在ConfigureServices里对同一接口再注册一次新实现即可覆盖last registration wins这是模块替换核心行为的标准手法属性注入慎用仅限特殊场景抽象类或极简单的服务如Logger、Localizer构造函数注入永远是第一选择。延伸阅读核心文档与源码路径想继续深入以下资料按阅读顺序排列依赖注入入门dev-docs/getting-started/dependency-injection.mdDI 最佳实践dev-docs/advanced/di-best-practices.md启动器基类src/Smartstore/Engine/Builders/StarterBase.cs作用域访问器src/Smartstore/Engine/ILifetimeScopeAccessor.cs延迟解析 Work 类src/Smartstore/Engine/Work.cs模块开发指南Startup 约定dev-docs/compose/modules/getting-started-with-modules.md掌握注册在 Starter、解析靠构造、作用域分场景这三句话你就已经能读懂 Smartstore 绝大部分服务的生命周期管理逻辑可以自信地开始编写自己的第一个模块了。【免费下载链接】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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表