有人可以详细解释一下IOC容器的使用方法吗？我通过参数和构造函数广泛使用依赖注入。我理解这个学位的原理并对此感到满意。在我的大型项目中，我最终注入了太多的依赖项（任何高达两位数的东西都感觉很大——我喜欢术语“通心粉代码”）。所以我一直在考虑IOC容器。我已经阅读了一些关于它们的文章，但到目前为止我还没有看到它的好处。我可以看到它如何帮助发送相关对象组或一遍又一遍地获取相同类型。我不确定它们如何在我的项目中帮助我，我可能有一百多个实现相同接口的类，并且我以不同的顺序使用它们。那么，谁能给我指出一些好的文章，这些文章不仅描述了IOC容器的概念（最好不要特别夸大它们），而且还详细说明了它们如何使我在此类项目中受益，以及它们如何适合我的范围。一座大建筑物？我希望看到一些非特定语言的内容，但如果需要，我选择的语言是C#。控制反转主要是关于依赖管理和提供可测试的代码。从经典的方法来看，如果一个类有依赖关系，那么自然的趋势是让依赖类直接控制它的依赖关系。这通常意味着具有依赖关系的类将在构造函数中“新建”其依赖关系，或在其方法中按需提供它们。控制反转只是......它反转了创建依赖项的内容，将该过程外部化并将它们注入到具有依赖项的类中。通常，创建依赖关系的实体就是我们所说的IoC容器，它不仅负责创建和注入依赖关系，还负责管理它们的生命周期，确定它们的生存方式（更多关于此），并提供其他多种选择能力。（这是基于CastleMicroKernel/Windsor，这是我选择的IoC容器……它写得很扎实，非常实用，并且可扩展。如果你有更简单的需求，像Ninject，MicrosoftUnity和其他IoC容器更简单。Spring。NET.)假设您有一个可以在本地上下文或远程上下文中使用的内部应用程序。根据某些可检测的因素，您的应用程序可能需要加载服务的“本地”实现，而在其他情况下，它可能需要加载服务的“远程”实现。如果您遵循经典方法，并直接在具有这些依赖项的类中创建依赖项，则该类将被迫打破关于软件开发的两个非常重要的规则：关注点分离和单一职责。你越过了关注线，因为你的类现在关注的是它的内在目的，以及决定应该创建哪些依赖项以及如何创建它们的关注点。该类现在也负责许多事情而不是一个，并且有很多原因要改变：它的内在目的改变了，它的依赖项的创建过程改变了，它发现远程依赖项的方式改变了，它的依赖项可能需要什么依赖项，等。通过反转依赖管理，您可以改进系统架构并维护SoC和SR（或者当您之前由于依赖而无法维护时）。作为外部实体，IoC容器现在控制依赖项的方式。创建和注入后，您还可以获得额外的功能。容器可以管理依赖的生命周期，以更灵活的方式创建和销毁它们，从而提高效率。您还可以管理对象的生活方式。如果你有一个非常频繁地创建、使用和返回的依赖项，但很少或没有状态（例如工厂），你可以为它们提供池化生活方式，这将告诉容器自动创建该特定依赖项的对象类型池。存在多种生活方式，像温莎城堡这样的容器通常可以让您创造自己的生活方式。更好的IoC容器，如CastleWindsor，也提供了很多可扩展性。默认情况下，Windsor允许您创建本地类型的实例。可以创建工具来扩展Windsor的类型创建功能，以在运行时动态创建Web服务代理和WCF服务主机，而不是手动创建它们或使用svcutil（我最近刚做的）之类的工具静态创建它们。)许多工具可以使IoC支持现有的框架，例如NHibernate、ActiveRecord等。最后，IoC强制执行确保单元可测试代码的编码风格。使代码单元可测试的关键因素之一是外部化依赖管理。如果没有提供替代（模拟、存根等）依赖项的能力，孤立地测试单个代码“单元”是一项非常困难的任务，这使得集成测试成为自动化测试的唯一替代方案。由于IoC要求您的类通过注入（通过构造函数、属性或方法）接受依赖项，因此通常（如果不总是）将每个类简化为单个关联的责任和完全可模拟的依赖项。IoC=更好的架构、更强的凝聚力、更好的关注点分离、更容易减少到单一职责类、易于配置和互换的依赖项（通常无需重新编译代码）、灵活的依赖项生活方式和生命周期管理以及可单元测试的代码。IoC是一种生活方式……一种哲学，一种解决常见问题并满足关键最佳实践（如SoC和SR）的方法。即使（或者更确切地说）单个接口有数百种不同的实现，IoC也有很多可以提供的。可能需要一段时间才能完全理解它，但是一旦您完全理解IoC是什么以及它可以为您做什么，您将永远不想以任何其他方式做任何事情（除了嵌入式系统开发......）)如果你有一百多个类实现了一个公共接口，IoC也无济于事，你需要一个工厂。这样，您可以执行以下操作：publicinterfaceIMyInterface{//...}publicclassFactory{publicstaticIMyInterfaceGetObject(stringparam){//param是一个参数，可帮助Factory决定返回什么对象//（这只是一个例子，可能根本没有任何参数）}}//...//你不依赖于这里的特定实现IMyInterfaceobj=Factory.GetObject("someparam");在工厂内部，您可以使用IoC容器来检索对象（如果需要），但是您必须注册每个实现给定接口的类并将它们与某些键相关联（并使用这些键作为GetObject(）方法）。当您必须检索实现不同接口的对象时，IoC特别有用：IMyIntefacemyObject=Container.GetObject();IMyOtherInterfacemyOtherObjectContainer.GetObject();ISomeOtherInterfacesomeOtherObject=Container.GetObject();看？仅仅一个对象就可以得到多个不同类型的对象，不需要key（接口本身就是key）。如果你需要一个对象得到几个不同的对象，但都实现了相同的接口，那么IoC帮不了你多少。在过去的几周里，我已经从依赖注入转变为完全反转Castle中的控制，所以我明白你的问题出在哪里。我不想使用IOC容器的一些原因：这是一个不会增长那么多的小项目。如果构造函数和对这些构造函数的调用之间存在1:1的关系，那么使用IOC容器不会减少我必须编写的代码量。在您发现自己第二次复制并粘贴完全相同的“varmyObject=newMyClass(someInjectedDependency)”之前，您并没有违反“不要重复自己”。我可能需要调整现有代码以方便加载到IOC容器中。在你接触到一些更酷的面向方面的编程特性之前，这可能不是必需的，但是如果你忘记使一个方法成为虚拟的，密封该方法的类，它不实现接口，你正在做这些更多的改变是不舒服，然后使转换不那么吸引人。它为我的项目和我的团队增加了额外的外部依赖。我可以说服我团队的其他成员构建他们的代码以允许DI膨胀，但我目前是唯一知道如何使用Castle的人。对于较小、不太复杂的项目，这不是问题。对于较大的项目（具有讽刺意味的是，这些项目将从IOC容器中获益最多），如果我不能很好地使用IOC容器传播，那么在我的团队中成为一个特立独行的人并没有什么坏处任何帮助。我不想回到普通DI的一些原因：我可以在我的任意数量的类中添加或删除日志记录，而无需添加任何类型的跟踪或日志记录语句。能够在不更改这些类的情况下将我的类与其他函数交织在一起是非常强大的。例如：日志记录：http://ayende.com/Blog/archive/2008/07/31/Logging–the-AOP-way.aspx事务：http://www.codeproject.com/KB/architecture/introducingcastle。aspx（跳到事务部分）至少，Castle在连接类到依赖方面很有帮助，回去会很痛苦。例如，Castle缺少依赖项：“无法创建组件‘MyClass’，因为它具有满足的依赖项。服务正在等待以下依赖项：服务：-IMyService未注册。”没有Castle时缺少依赖项：对象引用InstanceDeadLast未设置为对象：通过编辑Xml文件在运行时交换注入服务的能力。我的意见是这是最苛刻的功能，但我认为它只是锦上添花。我宁愿用代码连接我所有的服务，但我相信我将来会遇到麻烦。我承认——作为IOC和Castle的新手——我可能只是肤浅，但到目前为止，我真的很喜欢我所看到的。我觉得我用它构建的最后几个项目真的能够应对我公司日常工作中不可预测的变化，这是我以前从未感受过的。试试这些：我没有链接，但可以给你举个例子：你有一个网络控制器需要调用一个有数据访问层的服务。现在，我把它放在你的代码中，你在编译时构建这些对象。您使用的是一个很好的设计模式，但是如果您需要更改saydao的实现，您将不得不进入代码并删除设置此依赖项的代码，重新编译/测试/部署。但是如果你想使用IOC容器，你只需要改变配置中的类并重启应用程序。JeremyFrey忽略了使用IOC容器的最大原因之一：它使您的代码更易于模拟和测试。鼓励使用接口还有许多其他好处：更好的分层、更容易动态生成代理，例如声明式事务、面向方面的编程和远程处理。如果您认为IOC仅适用于替换对“new”的调用，那么您不会明白。IoC容器通常会做依赖注入，这在某些项目中不是什么大不了的事情，但是一些提供IoC容器的框架提供了其他服务，值得使用它们。例如，Castle除了IoC容器之外还有完整的服务列表。动态代理、事务管理和NHibernate设施都是它的一部分。那么我认为您应该将IoCcontianers视为您的应用程序框架的一部分。下面是我使用IoC容器的原因：1.编写单元测试会更容易。你实际上可以写不同的配置来做不同的事情2.为不同的场景添加不同的插件（例如，为不同的客户）3.接受类为我们的代码添加不同的方面。4.由于我们使用的是NHibernate，Castle的事务管理和NHibernate的设施对于开发和维护代码非常有用。这就像我们应用程序的每个技术方面都是使用应用程序框架处理的，我们有时间考虑客户真正想要什么。以上是C#学习教程：谁能详细解释一下IOC容器的使用方法？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
