依赖注入 – 何时使用IOC容器？
发布时间：2020-12-14 00:52:21 所属栏目：百科 来源：网络整理
导读：我想知道什么时候应该使用容器，而不是手动注入依赖项。如果我有一个应用程序使用1-2个接口，并且每个接口只有1-2个具体的实现，我将倾向于仅仅处理自己。 如果我有一个使用2-3个接口的小应用程序，每个接口有2-3个具体的实现，我应该使用一个完整的容器？有
|
我想知道什么时候应该使用容器，而不是手动注入依赖项。如果我有一个应用程序使用1-2个接口，并且每个接口只有1-2个具体的实现，我将倾向于仅仅处理自己。
如果我有一个使用2-3个接口的小应用程序，每个接口有2-3个具体的实现，我应该使用一个完整的容器？有什么像this这样简单的东西就够了吗？ 基本上，我正在努力了解何时适合手动处理这些依赖项，何时(或者)我应该使用像上面这样简单的东西，何时使用像Ninject，Windsor等的IOC容器….它可能不会适当地把数字放在这样的东西上，但是如何才能告诉它是时候使用IOC容器？
这里要重要的一点是，您可以(并且应该)以
DI-friendly,but container-agnostic的方式编写代码。
这意味着您应该始终将依赖关系的组合推送到不可能延迟的位置。这被称为Composition Root，通常被放置在应用程序的入口点附近。 如果您以这种方式设计应用程序，则您选择的DI容器(或不含DI容器)将围绕应用程序的一个位置进行，您可以快速更改策略。 如果您只有几个依赖关系，您可以选择使用Poor Man’s DI，或者您可以选择使用完整的DI Container。以这种方式使用，您将不会依赖任何特定的DI Container，因此在可维护性方面的选择变得不那么重要。 DI容器可帮助您管理复杂性，包括对象生命周期。像这里所描述的那样，它不会做任何你不能手写的东西，但它更好，更简洁。因此，我何时开始使用DI Container的门槛将相当低。 一旦我超过了一些依赖关系，我将开始使用一个DI容器。 Most of them are pretty easy to get started with anyway。 更新：我的November 2012 answer to that question。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |