很少有人在.NET中使用控制反转(IOC)原理。我有一些与Java一起工作的朋友，他们使用Spring和PICoCube使用了更多的IOC。

我理解从代码中删除依赖项的原则…但我有一个疑问，它是如此的好。

为什么.NET程序员不使用(或少使用)这些类型的框架？如果你这样做了，你真的会发现长期的积极影响吗？

很多人在.NET中使用IOC，并且有几个框架可以帮助使用IOC。您可能在WinForms方面看得更少，因为当您在Visual Studio中设计表单时，很难让容器将所有内容连接在一起，但我可以说，对于服务器端.NET应用程序，至少在我工作的地方，IOC的使用非常成功。

为什么要在.NET中使用它？因为同样的原因，你在其他地方使用它。我最喜欢的两件事是：

• 针对IOC的设计倾向于执行良好的编码实践——接口设计、低耦合、高内聚性。这也导致了非常容易进行单元测试的类。
• 系统配置通常可以在不重新编译的情况下进行更改。

讨论.NET可用的不同IOC/DI框架的其他一些帖子：

• 哪些C/.NET依赖注入框架值得研究？
• 我应该使用哪个依赖注入工具？

我使用structuremap进行依赖项注入，最近才开始在ibatis.net中使用它在运行时注入域对象映射器(而不是通过XML配置文件，不，谢谢！).

我看到了立竿见影的好处。为所有映射器(如IPersonMapper创建接口，然后添加moq)允许我快速、轻松地编写一些非常好的无数据库单元测试。

以前(.NET 1.0)我编写自己的插件系统主要是为了了解反射。从那时起，我在我的项目中实施了某种IOC。直到最近，我才开始使用IOC来减少编写单元测试的痛苦。在这一点上，我无法想象以任何其他方式来做。

到目前为止，IOC在.NET中还不是那么普遍。这一切都与微软有关，也与他们所做的促销活动有关。到目前为止，他们更强调vs的rad能力，同时忘记了推广IOC和DI，但现在他们有了自己的框架，称为Unity，以及他们在ASP.NET MVC上所做的工作。

所以我想大多数人会开始使用这样的东西。因为知道他们有MS替代品。

我使用结构图。

关于ioc.net的使用有很多理论。我认为有相当多的开发人员在这方面没有经验。它们不是来自Java背景。它们来自经典的ASP和VB6背景。此外，直到最近，微软才真正推广使用IOC。

此外，使用IOC有几个假设。首先，你必须了解它的用途和你能从中得到什么。其次，必须开发代码，以便实际使用IOC容器。

国际奥委会不仅仅是在使用工具箱中的另一个项目。它是关于知道如何使用，知道何时使用它，以及作为开发人员的成熟。

因为它与.NET有关，所以我有几个IOC容器。我用过温莎，结构图，统一，最近还用过ninject。但请记住，我并没有在实际的应用程序中使用它们。我喜欢四处游玩，看看外面发生了什么。我发现ioc containers.net的市场相当好。

越来越普遍了。我目前的项目使用Spring，在我之前的项目中，我们使用了Castle Windsor。

现在，我想使用"约定优于配置"的思想来防止所有这些复杂的XML声明。

试试linfu.ioc 2.0：

http://www.codeproject.com/kb/cs/linfu_ioc.aspx

它是目前最灵活的IOC容器之一，和Ninject一样，没有需要维护的XML文件。然而，与Ninject不同，Linfu并不强制您编写任何绑定代码来将依赖项连接在一起。看一看！：)

我使用它来允许我的单元测试为上游依赖对象替换模拟类(模拟实际的生产类)，这样我的单元测试才真正地在一个类中执行和测试代码。方法是它们被写入测试中。