.net - 是否应该注入(inject)基础设施依赖项?

标签 .net inversion-of-control

对于记录器、安全性、配置等基础设施项目,这些东西应该真正注入(inject)到需要它们的每个类中,还是应该注入(inject)到服务定位器中,然后这些类可以使用服务定位器来解决依赖关系(或一些其他机制)?

所有类都有 10 个参数 ctor 来通过 DI 满足依赖关系,这看起来真的很荒谬。它是一种代码气味 IMO。我能理解诸如存储库或服务代理/连接器之类的东西,但不能理解日志。

最佳答案

有几个选择。

  • 使用属性注入(inject)并在 ctor 中设置默认值。例如
    class foo 
    {
        public ILogger Logger {get;set;}
    
        public foo()
        {
           Logger = NullLogger.Instance;
        }
    }
    
  • 使用 AOP 类型的方法。使用动态代理,您可以使用日志记录语句包装公共(public)调用,但日志记录实际上从未注入(inject)到组件本身中。见 Castle.DynamicProxy或自定义 .Net 属性以获取有关此方法的更多想法。

  • 那么问题来了,为什么要向组件中注入(inject)如此多的基础设施问题?您所描述的被认为是横切关注点,通常这是通过一些 AOP(面向方面​​的编程)来处理的,因此核心系统中没有很多重复。

    关于.net - 是否应该注入(inject)基础设施依赖项?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10853740/

    相关文章:

    assemblies - NInject 可以按需加载模块/程序集吗?

    c# - 是否可以在应用程序启动时不使用服务定位器来实现依赖注入(inject)?

    c# - 如何将 AutoMapper 与 Ninject.Web.Mvc 一起使用?

    c# - 使字段只能由其相应的属性访问?

    c# - WCF:没有 channel 主动监听

    c# - 隐藏面板应该强制下面的控件向上移动并调整表单大小

    c# - 带有 DI 和 IoC 的工厂方法

    c# - 格式化带有公制前缀的数字?

    C# "Method not found"未使用反射的运行时异常

    c# - CaSTLe Windsor/DelegatingHandler/IPrincipal 依赖注入(inject) (DI)/ASP.NET Web API 中的控制反转 (IoC)