我已经使用依赖注入(DI)有一段时间了，在构造函数、属性或方法中进行注入。我从未觉得有必要使用反转控制(IoC)容器。然而，我读得越多，我就越感到来自社区的使用IoC容器的压力。
我使用过StructureMap、NInject、Unity和Funq等。net容器。我仍然没有看到IoC容器将如何受益/改进我的代码。
我也害怕在工作中开始使用容器，因为我的许多同事会看到他们不理解的代码。他们中的许多人可能不愿意学习新技术。
请说服我，我需要使用IoC容器。当我在工作中与其他开发人员交谈时，我将使用这些论点。
当前回答
我只是碰巧正在把自己生长的DI代码拉出来，并用IOC替换它。我可能已经删除了200多行代码，用大约10行代码替换了它。是的，我必须学习如何使用容器(Winsor)，但我是一名在21世纪从事互联网技术工作的工程师，所以我已经习惯了。我大概花了20分钟看了一下怎么做。这很值得我花时间。
其他回答
IoC容器也适用于装入嵌套很深的类依赖项。例如，如果你有以下代码使用依赖注入。
public void GetPresenter()
{
var presenter = new CustomerPresenter(new CustomerService(new CustomerRepository(new DB())));
}
class CustomerPresenter
{
private readonly ICustomerService service;
public CustomerPresenter(ICustomerService service)
{
this.service = service;
}
}
class CustomerService
{
private readonly IRespository<Customer> repository;
public CustomerService(IRespository<Customer> repository)
{
this.repository = repository;
}
}
class CustomerRepository : IRespository<Customer>
{
private readonly DB db;
public CustomerRepository(DB db)
{
this.db = db;
}
}
class DB { }
如果你把所有这些依赖都加载到一个IoC容器中，你可以解析CustomerService，所有的子依赖都会自动得到解析。
例如:
public static IoC
{
private IUnityContainer _container;
static IoC()
{
InitializeIoC();
}
static void InitializeIoC()
{
_container = new UnityContainer();
_container.RegisterType<ICustomerService, CustomerService>();
_container.RegisterType<IRepository<Customer>, CustomerRepository>();
}
static T Resolve<T>()
{
return _container.Resolve<T>();
}
}
public void GetPresenter()
{
var presenter = IoC.Resolve<CustomerPresenter>();
// presenter is loaded and all of its nested child dependencies
// are automatically injected
// -
// Also, note that only the Interfaces need to be registered
// the concrete types like DB and CustomerPresenter will automatically
// resolve.
}
因为所有的依赖关系都是清晰可见的，所以它可以促进创建松散耦合的组件，同时在整个应用程序中易于访问和重用。
Ioc容器解决了一个你可能没有的问题，但这是一个很好的问题
http://kozmic.net/2012/10/23/ioc-container-solves-a-problem-you-might-not-have-but-its-a-nice-problem-to-have/
依赖注入在ASP。NET项目可以用几行代码完成。我认为，当你的应用程序使用多个前端并需要单元测试时，使用容器会有一些好处。
都快三年了，是吧?
在支持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();
}
｝ ｀ 我们需要一个框架来做这件事，为什么?
