设计网站定制公司,百度收录申请,开发软件开发外包,钱包网站建设我们知道依赖注入#xff08;DI#xff09;是一种实现对象及其协作者或依赖关系之间松散耦合的技术。 ASP.NET Core包含一个简单的内建容器来支持构造器注入。我们试图将DI的最佳实践带到.NET Core应用程序中#xff0c;这表现在以下方面#xff1a;构造器注入注册组件DI i… 我们知道依赖注入DI是一种实现对象及其协作者或依赖关系之间松散耦合的技术。 ASP.NET Core包含一个简单的内建容器来支持构造器注入。我们试图将DI的最佳实践带到.NET Core应用程序中这表现在以下方面构造器注入注册组件DI in testing构造器注入我们可以通过方法注入、属性注入、构造器注入的方式来注入具体的实例一般来说构造器注入的方式被认为是最好的方式所以在应用程序中将使用构造器注入请避免使用别的注入方式。一个构造器注入的例子如public class CharacterRepository : ICharacterRepository{    private readonly ApplicationDbContext _dbContext;    public CharacterRepository(ApplicationDbContext dbContext)    {        _dbContext dbContext;    }}注册组件到容器在使用DI之前需要告诉容器组件之间的对应关系例如container.RegisterIAService, AService();所以当你使用构造器注入的时候你告诉构造函数需要注入IAService类型的实例容器会根据你之前注册的对应关系创建AService的实例。看起来一切都很简单但在实际应用过程中并没有这么简单试想在一个项目中组件有成千上万个这成千上万个组件之间的对应关系怎么样维护一个稍微改进点的策略根据这些组件的职责分类把某一类组件的对应关系抽取成方法private void RegisterApplicationServices(Container container){    container.RegisterIAApplicationService, AApplicationService();    container.RegisterIBApplicationService, BApplicationService();    //...}private void RegisterDomainServices(Container container){    container.RegisterIADomainService, ADomainService();    container.RegisterIBDomainService, BDomainService();    //...}private void RegisterOtherServices(Container container){    container.RegisterIDataTimeSource, DataTimeSource();    container.RegisterIUserFetcher, UserFetcher();    //...}这两个分类有什么特点呢第一个方法试图把所有的ApplicationService的组件对应关系汇总在一起第二个方法试图把所有的DomainService的组件对应关系汇总在一起比起之前已经有了很大的进步。不过随着组件的增加你需要不断修改这几个方法。基于公共接口来注册组件第一个方法已经找到了同一类的组件既然这些组件的性质是一样的就可以用同样的接口来表示定义一个空接口用来表示ApplicationService:public interface IApplicationService {}public interface IAApplicationService : IApplicationService { //.. }public interface IBApplicationService : IApplicationService { //.. }一旦这些组件有了公共特点尝试创建下面的扩展container.Register(Classes.FromAssembly().BaseOnIApplicationService().WithDefaultInterface());这句代码的意思是显而易见的扫描某个程序集找到所有实现了IApplicationService的类进而把组件的对照关系注册到了容器中。当组件拥有多个接口类是可以拥有多个接口的在实际开发中这样的设计也是很常见的public interface IOptions { //... }public interface IAlipayOptions : IOptions { //... }public class AlipayOptions: IAlipayOptions { //... }利用上面介绍的扩展注册所有Options:container.Register(Classes.FromAssembly().BaseOnIOptions().WithDefaultInterface());尝试通过下面的构造器注入public AlipayPayment(IAlipayOptions alipayOptions) { //... }工作的很好没有问题。但是当我们试图从容器里拿到所有的IOptions类型container.ResolveAllIOptions();你得不到任何IOptions类型的实例原因在于向容器注册对应关系的过程是一对一的我们之前的扩展.WithDefaultInterface()只注册了AlipayOptions和IAlipayOptions的关系如果想通过上面的方式拿到所有继承了IOptions的实例则需要使用另一个扩展container.Register(Classes.FromAssembly().BaseOnIOptions().WithAllInterfaces());把注册文件放在正确的位置我们通过分层的方式隔离了不同职责的程序集最终Web/API项目将会引用这些低层的程序集。要想把 Web/API启动起来需要把所有程序集定义的组件注册在Web/API项目的容器中。我们把Web/API这种能够启动的程序集叫做客户端。所以一个典型的客户端需要通过下面代码来注册DI容器container.Register(Classes.FromAssembly().BaseOnIApplicationService().WithDefaultInterface());container.Register(Classes.FromAssembly().BaseOnIDomainService().WithDefaultInterface());//...// 还有其他无法用公共接口表示的组件这些组件可能来自于低层服务container.RegisterIDateTimeSource, DateTimeSource();container.RegisterIUserFetcher, UserFetcher();//...这段代码描述了一个现象Web/API客户端对低层的组件对应关系一清二楚违反了Tell, Dont Ask Priciple. 正确的做法是Web/API客户端告诉低层组件帮我安装你所在的程序集中所有的组件对应关系。// 安装所有services.Install(FromAssembly.ContainsIApplicationService());services.Install(FromAssembly.ContainsIDomainService());services.Install(FromAssembly.ContainsIOtherService());具体的组件对应关系应该定义在相应的程序集中。这一节的思想都来源于Windsor Castle。DI in testing人们在不断讨论单元测试的各种风格和差异类似于通过Mock来管理依赖的单元测试被认为是一种反模式。见To Kill a Mockingtest, 而DI的另一个功能在于便于写出有价值和有效的单元测试。当你选择测试一个组件时实际上要花很多的时间来准备依赖数据这是显而易见的因为组件并不是独立存在的。试想如果你能从容器中拿到这个组件容器就会将所有的依赖关系创建好。但是问题来了比如说你的被测试组件依赖了一个能够给第三方发送请求的组件这显然并不是你所期望的你只需要注册一个假的事先准备好的组件即可。对ApplicationServiceTests的组件注册如下container.Install(FromAssembly.ContainsFakedComponentsInstaller());//..Register other components that ApplicationService depend on一个对SearchService的测试如下[Fact]public async void WhenInputDataIsValidShouldGetSearchResult(){    //Arrage    var searchService _container.ResolveISearchService();    var searchModel SearchModelBuilder.Default().Build();    //Act    var result await searchService.Search(searchModel);    //Assert    result.Count.Should().BeGreaterThan(0);}原文地址https://www.cnblogs.com/xiandnc/p/9407856.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com