我已经使用依赖注入(DI)有一段时间了，在构造函数、属性或方法中进行注入。我从未觉得有必要使用反转控制(IoC)容器。然而，我读得越多，我就越感到来自社区的使用IoC容器的压力。
我使用过StructureMap、NInject、Unity和Funq等。net容器。我仍然没有看到IoC容器将如何受益/改进我的代码。
我也害怕在工作中开始使用容器，因为我的许多同事会看到他们不理解的代码。他们中的许多人可能不愿意学习新技术。
请说服我，我需要使用IoC容器。当我在工作中与其他开发人员交谈时，我将使用这些论点。
当前回答
都快三年了，是吧?
在支持IoC框架的评论中，有50%的人不理解IoC和IoC框架之间的区别。我怀疑他们是否知道无需部署到应用服务器就可以编写代码 如果我们以最流行的Java Spring框架为例，IoC配置从XMl转移到代码中，现在看起来是这样的
“@ configuration 公共类AppConfig {
public @Bean TransferService transferService() {
return new TransferServiceImpl(accountRepository());
}
public @Bean AccountRepository accountRepository() {
return new InMemoryAccountRepository();
}
｝ ｀ 我们需要一个框架来做这件事，为什么?
其他回答
在。net世界里AOP还不是很流行，所以对于依赖注入来说，一个框架是你唯一真正的选择，不管你是自己写一个框架还是使用另一个框架。
如果您使用AOP，则可以在编译应用程序时进行注入，这在Java中更为常见。
DI有很多好处，比如减少耦合，从而使单元测试更容易，但是您将如何实现它呢?你想用反射来自己做吗?
在我看来，IoC的最大好处是能够集中配置依赖项。
如果你正在使用依赖注入，你的代码可能是这样的
public class CustomerPresenter
{
public CustomerPresenter() : this(new CustomerView(), new CustomerService())
{}
public CustomerPresenter(ICustomerView view, ICustomerService service)
{
// init view/service fields
}
// readonly view/service fields
}
如果你使用静态IoC类，而不是(恕我直言)更混乱的配置文件，你可以有这样的东西:
public class CustomerPresenter
{
public CustomerPresenter() : this(IoC.Resolve<ICustomerView>(), IoC.Resolve<ICustomerService>())
{}
public CustomerPresenter(ICustomerView view, ICustomerService service)
{
// init view/service fields
}
// readonly view/service fields
}
然后，你的静态IoC类看起来像这样，我在这里使用Unity。
public static IoC
{
private static readonly IUnityContainer _container;
static IoC()
{
InitializeIoC();
}
static void InitializeIoC()
{
_container = new UnityContainer();
_container.RegisterType<ICustomerView, CustomerView>();
_container.RegisterType<ICustomerService, CustomerService>();
// all other RegisterTypes and RegisterInstances can go here in one file.
// one place to change dependencies is good.
}
}
不需要IoC容器。
但是如果您严格遵循依赖注入模式，您会发现使用一个依赖注入模式将会删除大量冗余的、无聊的代码。
无论如何，这通常是使用一个库/框架的最佳时机——当你了解它在做什么并且不需要库也能完成它的时候。
因为所有的依赖关系都是清晰可见的，所以它可以促进创建松散耦合的组件，同时在整个应用程序中易于访问和重用。
使用容器主要是将命令式/脚本化的初始化和配置风格改为声明式的。这可能会有一些不同的有益影响:
减少主程序启动的繁琐程序。 支持相当深入的部署时重新配置功能。 使依赖注入样式成为新工作阻力最小的路径。
当然，可能会有困难:
需要复杂启动/关闭/生命周期管理的代码可能不容易适应容器。 你可能需要处理个人、流程和团队文化方面的问题——但这就是你为什么要问…… 一些工具包本身正在迅速成为重量级的工具，鼓励了许多依赖注入容器开始反对的那种深度依赖。
