我试图了解何时应该使用容器而不是手动注入依赖项。如果我有一个使用1-2接口的应用程序，并且每个接口只有1-2个具体实现，我会倾向于自己处理。
如果我有一个使用2-3个接口的小应用程序，每个接口有2-3个具体实现，我应该使用一个完整的容器吗？像this这样简单的东西就足够了吗？
基本上我正在尝试理解何时适合手动处理这些依赖项，何时（或者如果）我应该使用像上面那样简单的东西，何时使用像Ninject，Windsor等的IOC容器....将数字放在这样的东西上可能不合适，但我怎么能告诉它是时候使用IOC容器呢？
答案 0 :(得分：14)
这里要认识到的重要一点是，您可以（并且应该）以DI-friendly, but container-agnostic方式编写代码。
这意味着您应该始终将依赖项的组合推送到您不能再推迟它的点。这称为Composition Root，通常位于应用程序的入口点附近。
如果您以这种方式设计应用程序，您选择的DI容器（或无DI容器）将围绕应用程序中的单个位置进行，您可以快速更改策略。
如果你只有一些依赖关系，你可以选择使用穷人的DI ，或者你可以选择使用一个成熟的 DI容器。以这种方式使用，您将不依赖于任何特定的DI容器，因此在可维护性方面，选择变得不太重要。
DI容器可帮助您管理完整性，包括对象生命周期。像这里描述的那样使用它，它不会做任何你不能写的东西，但它确实更好，更简洁。因此，我何时开始使用DI容器的门槛非常低。
一旦我遇到一些依赖项，我就会开始使用DI容器。 Most of them are pretty easy to get started with anyway