我已经使用依赖注入(DI)有一段时间了，在构造函数、属性或方法中进行注入。我从未觉得有必要使用反转控制(IoC)容器。然而，我读得越多，我就越感到来自社区的使用IoC容器的压力。
我使用过StructureMap、NInject、Unity和Funq等。net容器。我仍然没有看到IoC容器将如何受益/改进我的代码。
我也害怕在工作中开始使用容器，因为我的许多同事会看到他们不理解的代码。他们中的许多人可能不愿意学习新技术。
请说服我，我需要使用IoC容器。当我在工作中与其他开发人员交谈时，我将使用这些论点。
当前回答
就我个人而言，我使用IoC作为我的应用程序的某种结构图(是的，我也喜欢StructureMap;))。这使得在测试期间用Moq实现代替我通常的接口实现变得很容易。创建一个测试设置可以像对我的ioc -框架进行一个新的初始化调用一样简单，用一个mock代替任何一个测试边界类。
这可能不是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.
}
}
因为所有的依赖关系都是清晰可见的，所以它可以促进创建松散耦合的组件，同时在整个应用程序中易于访问和重用。
依赖注入在ASP。NET项目可以用几行代码完成。我认为，当你的应用程序使用多个前端并需要单元测试时，使用容器会有一些好处。
