问ASP.NET MVC3 Hand coding IoC

EN

我认为在没有DI容器的情况下开始是一个很好的练习。在专注于使用依赖注入框架之前，请专注于最佳模式和实践。特别是，围绕依赖注入设计所有类，并确保您的代码遵循SOLID原则。这两个听起来都很容易，但这需要转变思维方式和大量的练习，然后你才能做到这一点(但这是非常值得的)。

当你做到这一点，并且做得很好，你会很快注意到你的应用程序将以惊人的方式发展。您的代码将以您以前从未想象过的方式进行测试和扩展，而您的代码不会随着时间的推移而腐烂(但是，它会持续关注以防止代码腐烂)。

尽管如此，当你把所有这些都做好了(再说一次，这需要大量的练习)，你仍然会有一部分应用程序，尽管你尽了最大的努力，但随着应用程序的增长，它将变得更加复杂和难以维护。这是应用程序中将所有依赖项连接在一起的部分：Composition Root。

这就是DI容器的用武之地。他们有花哨的名字，并在功能上相互竞争，但他们的目标可以用一句话来表述：

DI容器的目标是保持组成根的可维护性。

虽然您可以编写自己的简单DI容器来连接您的依赖项，但为了防止您的crucial变成一个脆弱的、不断变化的泥球，容器必须至少有一个关键功能:自动构造函数注入( Automatic Constructor Injection，也称为.自动布线)。使用自动连接，容器将查看它需要创建的类型的构造函数参数，并且它将根据这些参数的类型向其中注入依赖项。此功能将区分维护噩梦和健康的组合根。尽管创建支持自动连接的容器并不困难(使用表达式树，它需要大约20行代码)，但当您开始需要自动连接时，就是开始使用现有DI框架之一的时候了。

因此，总而言之，如果您觉得手动操作有助于您的学习体验，请这样做，只要您坚持使用SOLID、DI、DRY和TDD。当为应用程序中的每个更改更改组成根的负担变得太大时(这将比您预期的更快)，请切换到已建立的框架。

不使用

可以实现IoC吗？

是的，可以在不使用任何XML的情况下配置Ninject、Unity、Castle Windsor和Autofac。(不确定Spring.NET，上次我用它是不可能的，1.3版)

根据我的理解，如果错误，请纠正，IoC可以与DI一起使用，使类的功能基于其定义和实现，同时允许分离关注点。

如果在" IoC“下你的意思是"IoC容器”，那么是的，它可以与DI一起使用，但由于DI是控制反转的特殊情况，你的IoC容器将只是你的依赖项的容器。仅仅拥有它，你将不会神奇地得到任何DI友好的类型。它只是对管理反向依赖项的支持。

编辑

正如Mystere Man在他的回答中指出的那样，您需要提高对IoC容器的理解。因此，我建议阅读这篇(来自Mark Seeman的)关于所有这些东西的wonderful book。

我建议首先使用现有的DI容器，以便从最终用户的角度了解它是如何工作的。然后你就可以重新设计轮子了。我最喜欢的一句话是“你必须先知道规则，然后才能打破它们”。

你所说的一些话没有多大意义。据我所知，你不必在任何框架中使用System.ComponentModel.IContainer。也许Unity需要这个(微软的容器)，但其他的都不需要。我不熟悉Unity thogh。