我试图了解何时应该使用容器而不是手动注入依赖项。如果我有一个使用 1-2 个接口的应用程序，并且每个接口只有 1-2 个具体实现，我会倾向于自己处理。
如果我有一个使用 2-3 个接口的小型应用程序，并且每个接口有 2-3 个具体实现，我应该使用成熟的容器吗？会一些简单的事情吗this http://ayende.com/Blog/archive/2007/10/20/Building-an-IoC-container-in-15-lines-of-code.aspx够了吗？
基本上我试图了解何时适合手动处理这些依赖项，何时（或是否）我应该使用像上面这样简单的东西，以及何时使用像 Ninject、Windsor 等这样的 IOC 容器......它可能不会给这样的东西加上一个数字是合适的，但是我怎么知道是时候使用 IOC 容器了呢？
这里要认识到的重要一点是，您可以（并且应该）在DI 友好，但与容器无关 https://stackoverflow.com/questions/2045904/dependency-inject-di-friendly-library/2047657#2047657 manner.
这意味着您应该始终将依赖项的组合推到无法再推迟的程度。这被称为成分根 https://stackoverflow.com/questions/1475575/where-should-i-do-dependency-injection-with-ninject-2/1475861#1475861通常放置在应用程序的入口点附近。
如果您以这种方式设计应用程序，那么您对 DI 容器（或无 DI 容器）的选择将围绕应用程序中的单个位置进行，并且您可以快速更改策略。
您可以选择使用穷人的DI如果您只有几个依赖项，或者您可以选择使用成熟的DI容器。以这种方式使用，您将不依赖于任何特定的 DI 容器，因此选择变为不太重要在可维护性方面。
DI 容器可帮助您管理复杂性，包括对象生命周期。像这里描述的那样使用，它不会做任何你无法手写的事情，但它可以做到更好更简洁。因此，我何时开始使用 DI 容器的门槛非常低。
一旦我克服了一些依赖关系，我就会开始使用 DI 容器。无论如何，他们中的大多数都很容易上手 https://stackoverflow.com/questions/2515124/whats-the-simplest-ioc-container-for-c/2515178#2515178.
更新：我的2012年11月回答这个问题 http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
