ASP.NET MVC3手动编码IoC
本文关键字：编码 IoC NET MVC3 ASP | 更新日期: 2023-09-27 18:21:35
Ninject、Sprint.NET、Unity、Autofac、Castle、Windsor都是可用的IoC框架。然而，我喜欢自己写作的学习曲线和控制力。不"重新发明轮子"，只使用预先存在的结构，这无疑是一种常见的做法。如果你的评论是这样的，请温和一点。
IoC可以在不使用XML的情况下实现吗？在我看来，上述框架中的大多数（如果不是全部的话）都使用XML，但我更愿意用C#编写我的框架，而不是用XML加载.dll。无论如何，C#最终都会转换成一个.dll。
根据我的理解，如果错误，请纠正，IoC可以与DI一起使用，使类的功能基于它们的定义和实现，同时允许关注点的分离。
这是在C#中使用微软的库System.ComponentModel.IContainer通过一个继承它的类来实现的。一个类，如Product，将有一个接口IProduct。然后，泛型构造函数将从IContainer继承，并在构造函数中，允许传入存储库、传入实例化对象和传入函数。这将允许控制器操作实例化接口（IProduct），用当前存储库实例实例化泛型构造函数，然后将接口和函数传递给它。
这个设置准确吗？
我仍在努力了解更多关于这个主题的信息，并阅读了关于IoC、DI的wiki文章，以及关于Castle、Windsor、ninject、Unity的文章，并查看了MSDN中关于所使用的C#库的多个定义。如有任何协助、更正或建议，我们将不胜感激。感谢
IoC可以在不使用XML的情况下实现吗？
是的，可以在不使用任何XML的情况下配置Ninject、Unity、Castle Windsor和Autofac。（不确定Spring.NET，上次我使用它是不可能的，版本1.3）
根据我的理解，如果错误，请更正，IoC可以与DI使类的功能基于定义和实现，同时允许关注。
如果在"IoC"下你的意思是"IoC容器"，那么是的，它可以与DI一起使用，但由于DI是控制反转的特殊情况，你的IoC容器将只是你依赖的容器。只要拥有它，你就不会神奇地获得任何DI友好类型。它只是对管理反向依赖关系的支持。
编辑
正如神秘人在他的回答中指出的那样，你需要提高对IoC容器的理解。所以我建议你读一读这本关于这些东西的精彩的书（来自Mark Seeman）。
我认为在没有DI容器的情况下开始是一个很好的练习。在专注于使用DI框架之前，请关注最佳模式和实践。特别是，围绕依赖注入设计所有类，并确保您的代码遵循SOLID原则。两者听起来都很容易，但这需要心态的转变和大量的练习，然后你才能把这件事做好（但这是值得的）。
当你做到这一点，并且做得很好时，你会很快注意到你的应用程序将以惊人的方式发展。您的代码将以您从未想象过的方式进行测试和扩展，而不会随着时间的推移而腐烂（然而，它会不断关注以防止代码腐烂）。
尽管如此，当你把所有这些都做好了（这同样需要大量的练习），你的应用程序中仍然会有一个部分，尽管你尽了最大的努力，但随着应用程序的发展，它会变得更加复杂和难以维护。这是应用程序中将所有依赖关系连接在一起的部分：CompositionRoot。
这就是DI容器的用武之地。它们有着奇特的名称，并在功能上相互竞争，但它们的目标可以用一句话来说明：
DI容器的目标是保留Composition根可维护。
尽管你可以编写自己的简单DI容器来连接你的依赖关系，但为了防止你的Composition Root变成一个巨大的、脆弱的、不断变化的泥球，容器至少必须有一个关键功能：自动构造函数注入（也称为自动连接）。通过自动连接，容器将查看需要创建的类型的构造函数参数，并根据这些参数的类型在其中注入依赖项。此功能将区分维护噩梦和健康的Composition Root。尽管创建自己的支持自动连接的容器并不难（使用表达式树大约需要20行代码），但从开始需要自动连接的那一刻起，就是开始使用现有DI框架的时候了。
因此，总之，如果你觉得用手做这件事对你的学习体验有帮助，请这样做，只要你坚持SOLID、DI、DRY和TDD。当为应用程序中的每一次更改更改Composition Root的负担变得太大时（这将比您预期的更快），请切换到已建立的框架。
我建议首先使用现有的DI容器，从最终用户的角度了解它是如何工作的。然后你就可以重新设计轮子了。我最喜欢的一句话是"你必须知道规则，然后才能打破它们"。
你说的有些话没有多大意义。你不必在我所知道的任何框架中使用System.ComponentModel.IContainer。也许Unity需要（微软的容器），但其他人都不需要。我对Unity不熟悉。