Question

对于记录器，安全性，配置等基础设施项目，如果这些事情真的被注入到需要它们的每个类中，或者应该将它们注入到服务定位器中，然后类可以使用服务定位器来解析依赖项（或其他一些机制）？

所有具有10个参数ctors的类通过DI来满足依赖性，这看起来非常荒谬。它的代码闻到了IMO。我可以理解存储库或服务代理/连接器之类的东西，但不能记录日志。

Answer 1

有几种选择。

使用属性注入并在ctor中设置默认值。例如

class foo 
{
    public ILogger Logger {get;set;}

    public foo()
    {
       Logger = NullLogger.Instance;
    }
}

使用AOP类型方法。使用动态代理，您可以使用日志记录语句包装公共调用，但日志记录从未实际注入组件本身。有关此方法的更多建议，请参阅Castle.DynamicProxy或自定义.Net属性。

然后有一个问题，为什么这么多的基础设施问题被注入到组件中？你所描述的被认为是交叉问题，通常这是通过一些AOP（面向方面编程）来处理的，因此核心系统中没有很多重复。

Answer 2

这完全取决于您在基础架构和其余代码之间绘制线的位置。您认为数据库连接是基础架构吗？我没有。

属性注入是一种代码味道，因为它隐藏了依赖关系，并且在构造函数完成时类未正确初始化。仅用它来解决循环依赖。

对于非常具体的日志记录，我确实使用单例来获取记录器。

Normaly我会同意你对AOP的看法，但我不是运行时AOP框架的粉丝，团队也不了解AOP概念。他们几乎不了解IoC概念

您可能会发现我的IoC introduction有用。

Answer 3

关于日志记录 - 只需使用NLog（或您喜欢的记录器）并完成它。除非你处于一个非常奇怪的场景，否则没有理由抽象和/或注入你的记录器。

关于配置 - 只有少数类应该是配置的使用者，所以这不应该导致构造函数膨胀。有关配置和DI的详细讨论，另请参阅this question。

关于安全性 - 同样，我认为只有少数类应该是安全依赖性的消费者。如果许多课程涉及安全性，您可能需要重新审视您的设计。

一般情况下 - 如果一个类的构造函数参数太多，可能是因为它做得太多，无论依赖是否都是基础结构。