只是想继续了解 IOC 的原则。
Q1：静态方法 - 具有静态辅助方法的 util 类是否应该与 IOC 连接？
例如，如果我有一个带有许多静态方法的 HttpUtils 类，我是否应该尝试通过 IOC 将它传递给其他业务逻辑类？
以下问题可能是：
Q2：Singletons - 诸如日志之类的事情，您通常可以通过 Logger.getInstance() 类型调用访问它。您通常会保持原样，而不是使用 IOC 将记录器注入需要它的业务类吗？
Q3：静态类 - 我还没有真正使用过这个概念，但是如果您转向基于 IOC 的方法，您通常如何处理这个问题是否有任何指导方针。
提前致谢。
【问题讨论】：
标签： static inversion-of-control ioc-container ninject instance
关于 IoC 的有趣之处在于，以样式编写的对象通常与这些细节解耦。
我们以实用程序类为例：
public class HttpUtils
{
public static void DoStuff(int someValue)
{
// ...
}
}
在非 IoC 应用程序中，您可以直接使用该方法：
public class Foo
{
public int Value { get; set; }
public void DoStuff()
{
HttpUtils.DoStuff(Value);
}
}
但是，这会将DoStuff 的定义直接与其实现结合起来。 IoC 力求分离这些细节，因此我们自己定义操作：
public interface IDoesStuff
{
void DoStuff(int someValue);
}
然后，我们在Foo 中留出空间以供更改实现：
public class Foo
{
private readonly IDoesStuff _doesStuff;
public Foo(IDoesStuff doesStuff)
{
_doesStuff = doesStuff;
}
public int Value { get; set; }
public void DoStuff()
{
_doesStuff.DoStuff(Value);
}
}
这将Foo 与HttpUtils 分离。 DoStuff 概念的实现者现在是一个配置细节，而不是固有的依赖关系（因为它是静态方法）。
注意Foo 不知道它的IDoesStuff 是否是单例。该生命周期也是一个配置细节，而不是Foo的固有细节。
总而言之，IoC 和static 通常是矛盾的，因为 IoC 促进变革，而 static，顾名思义，阻止变革。在构造函数中声明依赖项，您会发现几乎从未使用过static 功能。
【讨论】：
HttpUtils.DoStuff 方法相同的耦合问题。因此，您不想要求 any 代码直接依赖于static 成员。相反，取HttpUtils.DoStuff 的主体，将其放在IDoesStuff 后面，并从HttpUtils 中完全删除该方法。现在，任何可能调用了静态方法的类都可以在其构造函数中接受IDoesStuff。 Viola：不再需要实用程序类！
IoC 容器通常用于注入具有状态的对象；或具有多个实现的类或接口，即使第二个实现是用于测试目的的模拟。如果这些都不正确，那么注入它您将一无所获。这些天最常见的习惯用法是让您的类前面有一个真实和模拟实现都可以实现的接口。
1) 辅助类上的静态方法 - 不，这些通常不会被 IoC 注入。通常它们是无状态实用程序。
举一个非常简单的例子，您不需要两个版本的实用方法StringUtils.Reverse()。您只需要一个，并且您可以轻松地围绕它编写测试，因为它没有状态或依赖项，因此模拟它绝对没有任何好处。示例测试：
string reversedString = StringUtils.Reverse("input");
Assert.AreEqual("tupni", reversedString)
如果实用程序不是真正无状态的（例如，依赖于 HttpContext.Current），那么您应该通过注入来明确依赖，而不是使实用程序静态。
2) 单例：通常是的，单例是注入的。但是关于 IoC 的一个好处是您不必担心是否只有其中之一。通过使用 IoC，您可以灵活地进行实例化。每次将特定类型作为单例或新实例的决定成为 IoC 容器配置的一部分，代码中没有其他任何内容需要更改。
因此，singleton-hood 不再是一个必须编码到类中的单独关注点（并且类在不需要时有多个关注点是不好的），它成为 IoC 容器的关注点。您不再使用诸如私有构造函数和public static GetInstance() 方法之类的特殊内容将类“作为单例”进行编码，您只需针对主要问题对其进行编码，而 IoC 容器的配置指定它是否为单例，或介于两者之间，例如每个线程一个实例。
3) 静态类 - 是静态方法的自然归宿。考虑在适当的情况下制作静态方法扩展方法。你不能注入这些类，因为你不能创建它们。使用静态类可以生成过程而不是面向对象的代码。这对于小型辅助方法来说并不是一件坏事，但如果大部分代码都是这样，那么您就没有使用 .Net 平台强大的 OO 功能。
【讨论】：
根据定义，静态方法不需要实例。 DI/IOC 旨在满足具有具体类的接口，并且鉴于您的静态类及其定义的静态方法不能实现接口或扩展类，这个问题没有任何意义。传递辅助类没有意义，因为不需要实例来使用静态方法。即使没有实例，您的代码也将始终执行相同的静态 helperr 方法。
在 IOC/DI 驱动的应用程序中，需要定义接口并至少有一个实现。这都是关于管理实例及其依赖关系的。
【讨论】：
当实用程序类需要访问数据库时，就会出现困境。而db访问器需要Ioc，因此实用程序类必须使用Ioc，所以它不能是静态的。
但我真的希望实用程序类是静态的，以便于使用。我不想填充每个需要实用程序类的消费类的构造函数。
消费类本身甚至可能不需要数据库访问。所以我不想注入 db 访问器并将其传递给实用程序类。
估计目前还没有完美的解决方案。总有一天希望我们更进一步，除了构造函数/属性注入，还有“全局上下文注入/配置”，或者说“静态注入”，将Ioc应用到对象创建之外。
想一想，为什么不呢？
【讨论】：