国际奥委会从头到尾答案

【问题标题】：IoC from start to finish国际奥委会从头到尾
【发布时间】：2010-04-16 06:04:03
【问题描述】：

我很确定 IoC 是适合我的应用程序的方式。这里有很多关于 SO 的文章甚至问题都在讨论不同的容器。我今天阅读了几篇博客，其中包含部分示例。我个人倾向于从 CommonServiceLocator 和 Unity 开始，作为解决同一问题的两种方法——我只需要一堆程序集来从数据库中获取数据，我认为这是需要在任何地方注入的数据。

我还没有找到任何真正从头到尾解决问题的网站，并附有具体的代码示例。例如，我还没有找到一个讨论 IServiceLocator 以及如何实际注册它（或做任何需要让它知道的事情）的文章。

您最喜欢哪些帖子/文章/SO 问题可以让菜鸟从头到尾完成实施？

【问题讨论】：

您很可能不需要或不需要 IServiceLocator
无论如何我都做不到，因为我还没有弄清楚。 ;) Unity 和 MEF 是我现在并行使用的。没有什么是灵丹妙药，但无论如何我都没有预料到。不过，我现在最关注的是 MEF。
MEF 不完全是 IoC 容器。如果您想要可插拔性 - 使用 MEF；如果您想要模块化，请使用实际的 IoC 容器，例如 Autofac 的 Windsor
而你当然不想使用服务定位器
@Dave：不完全一样。 MEF 更适合于潜在未知模块/插件的运行时发现。 IoC 容器在设计时更多考虑了静态注入。

标签： dependency-injection inversion-of-control unity-container common-service-locator

【解决方案1】：

如果你还没有读过，我推荐：

Martin Fowler 的“Inversion of Control Containers and the Dependency Injection pattern”
Miško Hevery 的“Dependency Injection Myth: Reference Passing”

（我还建议阅读ploeh blog - Mark 写的关于 DI 的文章和任何人一样好或更好）。

两者都没有提供端到端的应用示例，但它们共同提供了一个坚实的轮廓。

Fowler 的文章对于理解不同类型的依赖注入至关重要（根据您的问题，您可能已经阅读过它），但我确实必须阅读 Hevery 的文章，然后才能真正了解如何使用 DI世界。（而且您应该阅读更多 Hevery 的资料或 Mark Seemann 的“Service Locator is an Anti-Pattern”，以了解为什么您不应该使用服务定位器！）

最后，我不经常看到明确说明的一件事：您的顶级应用程序是the only things that should reference your dependency injection framework classes。

【讨论】：

【解决方案2】：

如果您仍然对使用 Unity 感兴趣，那么值得下载以下截屏视频 - Unity IoC Fundamentals。虽然它最后确实有真实世界的例子，但不幸的是，他完全通过了它们——尽管有博客文章的链接进一步解释了这些例子，如果有兴趣，你可以按照自己的节奏进行阅读。

【讨论】：