static - IOC - 具有静态辅助方法的 util 类是否应该与 IOC 连接？

Question

只是想继续了解 IOC 的原则。

Q1:静态方法 - 具有静态辅助方法的实用程序类是否应该与 IOC 连接？

例如，如果我有一个带有许多静态方法的 HttpUtils 类，我是否应该尝试通过 IOC 将它传递给其他业务逻辑类？

对此的问题可能是:

Q2:单例 - 诸如日志之类的事情，您通常可以通过 Logger.getInstance() 类型调用访问它。您通常会保持原样，而不是使用 IOC 将记录器注入(inject)到需要它的业务类中吗？

Q3:静态类 - 我还没有真正使用过这个概念，但是如果您转向基于 IOC 的方法，您通常如何处理这个问题是否有任何指导方针。

提前致谢。

Answer 1

IoC 容器通常用于注入(inject)具有状态的对象；或具有多个实现的类或接口(interface)，即使第二个实现是用于测试目的的模拟。如果这些都不正确，那么注入(inject)它您将一无所获。这些天最常见的习惯用法是让你的类前面有一个真实和模拟实现都可以实现的接口(interface)。

1) 辅助类的静态方法 - 不，这些通常不会被 IoC 注入(inject)。通常它们是无状态实用程序。

举一个非常简单的例子，您不需要两个版本的实用方法，称为 StringUtils.Reverse()。 .您只需要一个，并且您可以轻松地围绕它编写测试，因为它没有状态或依赖项，因此模拟它绝对没有任何好处。示例测试:

string reversedString = StringUtils.Reverse("input");
Assert.AreEqual("tupni", reversedString)

如果该实用程序不是真正无状态的(例如，依赖于 HttpContext.Current)，那么您应该通过注入(inject)来明确依赖，而不是使该实用程序成为静态的。

2) 单例 : 通常是的，单例被注入(inject)。但是关于 IoC 的一个好处是您不必担心是否只有其中之一。通过使用 IoC，您可以灵活地进行实例化。每次将特定类型作为单例或新实例的决定成为 IoC 容器配置的一部分，代码中没有其他任何内容需要更改。

因此，单例引擎不再是必须编码到类中的单独关注点(并且类在不需要时有多个关注点是不好的)，它成为 IoC 容器的关注点。您不会使用诸如私有(private)构造函数和 public static GetInstance() 之类的特殊内容将类“作为单例”进行编码。不再是方法，您只需针对主要问题对其进行编码，而 IoC 容器的配置指定它是否是单例，或者介于两者之间，例如每个线程一个实例。

3) 静态类 - 是静态方法的自然归宿。考虑在适当的情况下制作静态方法扩展方法。你不能注入(inject)这些类，因为你不能创建它们。使用静态类可以生成过程而不是面向对象的代码。这对于小型辅助方法来说并不是一件坏事，但如果大部分代码都是这样，那么您就没有使用 .Net 平台强大的 OO 功能。