IoC容器适用性/情景演示？

Question

.NET空间中的很多人拿起了温莎城堡，并在他们的项目中实施它，在过去的一年中，我一直在努力弄清楚为什么IoC容器似乎被视为一般的“最佳实践” ？我已经阅读了很多关于温莎等等的摘要和简要解释，但是其中的每一个都是抽象的，并且对于我所触及的大多数项目来说似乎都不实用，但最近我一直遇到很多使用Windsor的项目，我不明白为什么。

C＃/ .NET本质上支持基于接口的编码，抽象对象，委托和事件。我们可以从核心语言实现IoC，并且使用Reflection等实例化实现已知接口的未知实例，而不诉诸IoC容器库。

当应用YAGNI/AYGNI（你是否需要它？）我觉得温莎已被过度使用。我当然可以看到IoC容器的好处，但我认为这些好处是以额外的依赖性和元数据为代价的（IoC容器特有的属性和方法在核心代码中调用，.config文件在任何地方分散，app.config/web.config充满了绑定标签使得.config文件更难以编辑等），所以我试图找出折衷。

这就是说，我正在接受这种可能性，我正在对这些意见/声明做出全部所有关于无知的声明，因为我从未大量参与过使用Windsor或其他IoC容器库的项目。我真正需要的是有人展示一个“平均”或“典型”项目，在这个项目中使用了一个IoC容器库，为什么这应该是一个“最佳实践”，对我来说，它似乎使一个干净的项目变得凌乱与依赖和元数据。

如果有人知道任何博客帖子，文章或书籍，将填补我，这将是非常棒的。 （我不争论争吵的缘故，但因为我真的很想接受教育，是否应该让我自己了解IoC容器）。

Answer 1

好像你想要的答案this question

显然，如果如你所说，那么它不会是值钱，当你来到维护它的系统是很难建立。使用新技术时要记住这一点。有时旧的无聊的东西因为这个因素而更好。

温莎城堡使用反射本身，所以它真的是一个包装，以你想要的方式做事。如果您可以开发比CW更易于使用的系统，那么即使您在初始启动时花费您的时间，也应该这样做。这个成本将首先被CW的学习曲线所抵消，所以它不会像重新发明轮子那样。

他们这样做say themselves认为国际奥委会不适合小项目，

另外，根据大小和 项目的复杂性，一个IoC容器 可能是矫枉过正。倾向于 在大中型项目中使用它。

Answer 2

这不是一个直接回答你的问题，因为我不熟悉castle-windsor，而且我也不是IoC专家，但是从我对Java版Spring的经验中我可以看出，在这里，我们将讨论Spring，所以它可能并不是Castle-windsor的情况） 它不仅仅是依赖注入部分，它使得它很棒，而且框架本身也是：声明式事务管理，内置安全框架，ORM支持，内置的MVC Web框架，RMI，Web服务，电子邮件，AOP等等。它与IoC很好地集成在一起，在大多数典型场景中，fraework确实为您做了很多工作。

自动装配注释+ IDE支持（例如IntelliJ IDEA for Spring）我认为缓解了配置文件问题。

我不知道castle-windsor除了IoC容器外什么都没有，但如果是这样的话，也许就它作为框架的功能的丰富性而言，它还没有。

Answer 3

我不一定相信IoC容器在所有情况下都是好的。但它绝对可以。如果您使用依赖注入或服务定位器来处理依赖关系，您仍然有很长的路要走，但IoC容器可以帮助自动执行任务，为更高级的场景等提供支持。

我试图定义它为自己在博客中发布了好一会儿前：

控制反转（IOC）容器是一种非侵入性配置的智能工厂组件

拆分这个定义部分，我们得到

• 工厂，因为它负责为您创建对象。

• 智能，因为它明白你有什么依赖关系，并递归地为你创建它们。

• 可配置，因为您可以通过代码或配置文件配置使用情况。

• 非侵入性，因为使用的对象不需要知道容器。

  -

如果使用依赖注入或服务定位器模式你正确地使用它得到一些非常方便的好处。你不一定需要使用像Winsor这样的外部容器，但是这确实会给你一些额外的好处。

您可以编写实例化新对象的代码少得多。如果您想到更复杂的对象层次结构，则IoC容器可以帮助您自动创建整个链。这可能非常强大。

在测试过程中，您可以轻松地在测试过程中轻松添加模拟版本的对象（如果使用DI和/或SL）。例如，为自己创建一个服务定位器也可以解决这个问题。

更改要在注入构造函数中注入的依赖关系并不一定意味着您需要重构很多代码。

您通过一个来源获得隧道依赖的各种好处：装饰器，拦截器，代理以及处理对象生活方式。有了这样温莎的容器，这使你做一些硬的东西很简单，用极少的耦合

可以leviate其设施概念与例如NHibernate的

Answer 4

我建议你听插曲顺利整合2软件工程电台播客。这是一个关于依赖注入的整个情节。依赖注入是控制反转框架最广为人知的用法。我也建议听听有John Kovacs的DotNetRocks插曲362。 Here是该节目的成绩单。

现在IOC的副作用是提高可测试性。像温莎城堡这样的IOC容器的使用有助于解耦依赖。这种解耦使得单元测试更好。

大多数IOC框架还带有促进面向方面编程的方法。所以，如果你进入IOC容器框架可以帮助你。