具有多个 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 中创建视图/视图模型时，我一直遇到这种情况。事实上，我最近对 ​​Mark Seemann 博客中的一篇文章发表了如下评论：

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

如果您将 Castle Windsor 用于 DI，则可以使用 TypedFactoryFacility，它可以让您避免在工厂中引用容器。

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