有人能详细解释一下如何使用IOC容器吗？

Question

我通过参数和构造函数广泛使用依赖注入.我理解这个学位的原则,并对此感到满意.在我的大型项目中,我最终会注入太多的依赖项(任何达到双重数字的东西都会感觉很大 - 我喜欢"通心粉代码"这个术语).

因此,我一直在考虑IOC容器.我已经阅读了一些关于它们的文章,到目前为止我没有看到它的好处.我可以看到它如何协助发送相关对象组或一次又一次地获取相同类型.我不确定他们在我的项目中如何帮助我,我可能有超过一百个类实现相同的界面,并且我在不同的顺序中使用它们.

那么,任何人都能指出一些不仅描述IOC容器概念的好文章(最好不要特别夸大其中),还要详细说明它们在这类项目中如何使我受益,以及它们如何适合我的范围.一个大型的建筑？

我希望看到一些非语言特定的东西,但如果有必要我的首选语言是C#.

Answer 1

控制反转主要是关于依赖关系管理和提供可测试代码.从经典方法来看,如果一个类具有依赖性,那么自然趋势是赋予具有依赖性的类直接控制其依赖性.这通常意味着具有依赖关系的类将在构造函数中"新建"其依赖关系,或者在其方法中按需提供.

控制反转只是......它反转了创建依赖关系的东西,将该进程外部化并将它们注入具有依赖关系的类中.通常,创建依赖关系的实体就是我们所说的IoC容器,它不仅负责创建和注入依赖关系,还负责管理它们的生命周期,确定它们的生活方式(更多关于这一点),并提供多种选择其他能力.(这是基于Castle MicroKernel/Windsor,它是我选择的IoC容器......它写得很结实,非常实用,可扩展.如果你有更简单的需求,比如Ninject,Microsoft Unity和其他更简单的IoC容器Spring.NET.)

考虑您有一个可以在本地上下文或远程上下文中使用的内部应用程序.根据某些可检测因素,您的应用程序可能需要加载服务的"本地"实现,而在其他情况下,可能需要加载服务的"远程"实现.如果您遵循经典方法,并直接在具有这些依赖关系的类中创建依赖关系,那么该类将被迫打破关于软件开发的两个非常重要的规则:关注点分离和单一责任.您跨越了关注的边界,因为您的类现在关注其内在目的,以及确定它应该创建哪些依赖项以及如何创建的关注点.该类现在还负责许多事情,而不是一件事,并且有许多原因需要改变:它的内在目的改变,其依赖关系的创建过程发生变化,它发现远程依赖关系改变的方式,它的依赖关系可能需要什么依赖关系等

通过反转依赖关系管理,您可以改进系统架构并维护SoC和SR(或者,当您以前由于依赖关系而无法实现时).由于外部实体IoC容器现在控制着依赖关系的方式.创建和注入,您还可以获得额外的功能.容器可以管理依赖项的生命周期,以更灵活的方式创建和销毁它们,从而提高效率.您还可以管理对象的生活方式.如果您有一种非常频繁地创建,使用和返回的依赖关系,但是很少或没有状态(比如工厂),您可以给它们一种池化生活方式,这将告诉容器自动创建该特定依赖关系类型的对象池.存在许多生活方式,像温莎城堡这样的容器通常会让你有能力创造自己的生活方式.

更好的IoC容器,如Castle Windsor,也提供了很多可扩展性.默认情况下,Windsor允许您创建本地类型的实例.它可以创建扩展Windsor类型创建功能的工具,以便在运行时动态创建Web服务代理和WCF服务主机,无需使用svcutil等工具手动或静态创建它们(这是我最近刚才做的事情) .)许多工具可以使IoC支持现有的框架,如NHibernate,ActiveRecord等.

最后,IoC强制执行一种编码方式,以确保单元可测试的代码.使代码单元可测试的关键因素之一是外部化依赖关系管理.如果没有提供替代(模拟,存根等)依赖关系的能力,单独测试单个"单元"代码是一项非常困难的任务,使集成测试成为自动化测试的唯一替代方式.由于IoC要求您的类通过注入(通过构造函数,属性或方法)接受依赖关系,因此每个类通常(如果不是总是)被简化为单独的关联责任和完全可模拟的依赖关系.

IoC =更好的架构,更强的凝聚力,更好的关注点分离,更容易减少到单一职责的类,易于配置和可互换的依赖项(通常无需重新编译代码),灵活的依赖生活方式和生命周期管理,以及单元可测试代码.IoC是一种生活方式......一种哲学,一种解决常见问题和满足SoC和SR等关键最佳实践的方法.

甚至(或者更确切地说)具有数百种不同的单一接口实现,IoC可以提供很多功能.可能需要一段时间让你的头完全缠绕它,但是一旦你完全理解IoC是什么以及它能为你做什么,你永远不会想要以任何其他方式做事(除了嵌入式系统开发......) )

Answer 2

我没有链接，但可以为您提供一个示例：

您有一个 Web 控制器，需要调用具有数据访问层的服务。

现在，我在您的代码中认为您正在编译时自己构建这些对象。您正在使用一个不错的设计模式，但是如果您需要更改 dao 的实现，您必须进入代码并删除设置此依赖项的代码，重新编译/测试/部署。但如果您要使用 IOC 容器，您只需更改配置中的类并重新启动应用程序即可。