许多Windows的WPF应用程序中的依赖注入

Question

在将“依赖注入”与“业务线”应用程序一起使用时，拥有多个工厂是否“正确”？通过“业务线”应用程序，我指的是像SalesForce.com这样的应用程序或具有许多功能和相关窗口/表单的CRM系统。实际上，SalesForce.com可能是个坏榜样。 HTTP GET / POST机制创建了明显的组合根，可以在其中调用DI容器。但是，例如，长期运行的WPF应用程序是什么？如果在该会话期间不会调用其中许多函数，那么为所有可能的函数创建对象图似乎是浪费的，如果该人的角色限制了他们对应用程序的使用，则可能永远不会。

似乎解决方案是使用DI容器根据需要解析每个窗口/窗体。但是：

1. 这违反了仅在组合根处解析的DI原则，在这种情况下，在应用程序启动时解析父窗口。
2. 这将需要工厂创建窗口/表单以防止引用 应用程序代码中的DI容器。似乎工厂会迅速繁殖。

这似乎通过要求创建工厂来增加而不是降低复杂性，工厂的唯一功能是创建一个“人工”组合根来隐藏对DI Resolve方法的调用。

我也明白，理想情况下工厂不应该引用DI容器，但在这种情况下有一个对象图解决而不使用DI容器会要求我自己解决这些依赖，显然无法使用DI的目的容器

说实话，申请现在并不复杂，工厂也不会使问题复杂化。但是，我使用DI作为学习练习来编写这个孤立的应用程序，将它介绍给我自己和我所在的小开发团队。大多数团队都不熟悉DI，并且当需要额外的代码和类来隐藏DI容器的引入时，他会想知道DI的有效性。

FWIW，我确实拿到了Mark Seemann的“.NET中的依赖注入”的副本，但是WPF示例似乎太简单了，无法涵盖这个确切的场景，正如在介绍性文本中所期望的那样。他的示例在OnStartup事件中创建了一个MVVM表单。

任何见解都表示赞赏。感谢。

Answer 1

我在WPF和Silverlight中创建Views / ViewModel时遇到了这种情况。事实上，我最近对Mark Seemann博客中的一篇文章做了评论：

See my Comment at Monday, September 19, 2011 10:39:25 PM。 （帖子本身也很有趣，讨论Mark认为引用容器是可以接受的。）

如果您使用Castle Windsor作为DI，您可以使用TypedFactoryFacility，它允许您避免引用工厂中的容器。

使用Windsor时的一般方法是创建一个 调用Resolve（）并完成它的通用抽象工厂。这仍然感觉像是我的服务位置（即感觉“错误”），但我还没有找到另一个（非温莎）解决方案，这对于编码和维护并不痛苦。