IOC容器的最佳实践
我正在使用Unity IOC容器，我只是想知道访问多个类的容器的最佳方法是什么。
是否每个类都有一个IUnityContainer成员，然后通过构造函数传递容器？ 是否应该有一个带有IOC容器的单例类？
asp.net开发怎么样？
有人可以指导我朝正确的方向发展吗？ 谢谢。
恕我直言，不建议将整个容器注入类或具有应用程序范围的静态IoC服务定位器。
您希望能够从类的构造函数中看到（让我们称之为Foo），它使用什么样的服务/对象来完成工作。 这提高了透明度，可测试性和可脱气性。
让我们说Foo只需要电子邮件服务，但我传入整个容器和代码中的某个地方，电子邮件服务从容器中解析。 在这种情况下，将很难遵循。 相反，最好将电子邮件服务直接注入状态Foo的依赖关系更清晰。
如果Foo需要创建电子邮件服务的多个实例，最好创建并注入一个EmailServiceFactory（通过IoC容器），它将动态创建所需的实例。
在后一种情况下，Foo的依赖关系仍然尽可能具体 – 只有EmailServiceFactory可以创建的依赖关系。 如果我注入了整个容器，那就不清楚它提供的服务是Foo的确切依赖。
现在，如果我以后想要提供电子邮件服务的不同实例，我会在EmailServiceFactory中交换它。 如果它创建的所有服务都需要交换（例如在测试期间），我也可以换掉整个工厂。
因此，以创建一个额外的类（工厂）为代价，我得到了更清晰的代码，并且不必担心使用全局静态时可能发生的奇怪错误。 另外，当提供模拟测试时，我确切地知道它需要什么模拟，而不必模拟整个容器的类型。
这种方法也具有优势，现在，当模块初始化时（仅适用于Prism / Modularity），它不必注册它提供给IoC容器的所有类型的对象。 相反，它只需注册其ServiceFactory然后提供这些对象。
需要明确的是，模块的初始化类（实现IModule）仍应在其构造函数中接收应用程序范围的IoC容器，以便提供其他模块使用的服务，但容器不应侵入模块的类。
最后，我们这里有一个额外的间接层如何解决问题的另一个很好的例子。
将IOC容器放在进程中的最高级别/入口点，并使用它将依赖项注入其下的所有内容。
你可以注册容器本身，并像其他依赖属性一样注入，如下所示：
IUnityContainer container = new UnityContainer(); container.RegisterInstance(container); 需要访问它的类将具有以下属性：
private IUnityContainer unityContainer; [Dependency] public IUnityContainer UnityContainer { get { return unityContainer; } set { unityContainer = value; } }
因此，只要解决/建立了这种类的实例，就注入容器。
这更灵活，因为它适用于同一应用程序中的多个容器，而使用单例模式是不可能的。
如果所有对象都需要对容器的引用，那么您应该考虑重新编写代码。 虽然仍然比在任何地方调用新的更好，但它仍然分散了在整个代码中构建对象图的责任。 有了这种用法，它更像是一个ServiceLocator而不是IoC Container。
另一种选择是使用CommonServiceLocator ，尽管它可能是一个无意义的间接，你可以使用ServiceLocator.Current作为所有类已知的实例
我在我的博客上有一篇关于这个主题的post，我在使用t3mujin答案的内容。 随意使用它（不要打扰它的相关点…无关紧要）：
http://johanleino.spaces.live.com/blog/cns!6BE273C70C45B5D1!213.entry