不清楚如何实现依赖注入答案

【问题标题】：Unclear on how to implement dependency injection不清楚如何实现依赖注入
【发布时间】：2013-01-31 17:30:34
【问题描述】：

假设我有一个 LoginView，它的数据上下文 LoginViewModel 需要注入一个可以根据用户名/密码对用户进行身份验证的服务。

现在假设应用程序的状态是有人已经登录，但现在他们正在注销，我需要为下一个用户重新显示登录屏幕。所以此时我需要一个我的 LoginViewModel 的实例，但我不确定如何获取它。

我是否应该将 LoginViewModel 注入到我的 ShellViewModel 中并持有并重用它？这似乎很奇怪，因为我为什么要在不使用它的时候将它保存在内存中（当然，在这种情况下没什么大不了的，但可能适用于其他情况）。

我是否应该将身份验证服务注入 ShellViewModel 以便在需要创建 LoginViewModel 时保留？这看起来很奇怪，因为我的 ShellViewModel 不需要对这个服务做任何事情，如果这是答案，那么我会为它显示的所有其他 ViewModel 注入各种东西到我的 ShellViewModel 中。

而且我知道我不应该在我的应用程序根以外的任何地方引用我的 DI 容器，否则我将实施服务定位器模式。

诚然，我现在感觉很笨，当我听到答案时，我肯定会扇自己耳光……那是什么？

【问题讨论】：

标签： wpf design-patterns mvvm dependency-injection

【解决方案1】：

在这样的场景中，我通常会在您的情况下注入与 LoginViewModel 工厂相对应的内容。这样，您的逻辑就可以根据需要制造一个新的（或可能由工厂缓存的）实例。

【讨论】：

如果我的 ShellViewModel 有几十个不同的 ViewModel 可能会被显示并且都依赖于不同的服务怎么办。我会在我的 ShellViewModel 中注入 30 个工厂吗？
这似乎太过分了，我同意。我没有这种确切场景的经验，但您似乎可以利用某种代理范例，其中单个注入的代理可以根据参数制造任何必要的 ViewModel。
是的，这是我的下一个想法……但我试图看看这与直接引用我的 DI 容器有何不同。我知道这是不同的，但只是在这个特定的时刻不太明白为什么。
也就是说，引用我的 DI 容器会产生更多依赖于容器的代码......但除了需要切换 DI 容器的原因之外，我不确定为什么这样不好.
在我看来，DI的主要优势在于它减少了耦合。我工作的具体优势是它允许我们在测试时注入模拟对象而不是真实对象。

【解决方案2】：

在过去的几个小时里，除了查找关于这个主题的各种博客、问题和答案外，我什么也没做，我开始得出结论，像 Asp.net MVC 这样的框架可以实现纯粹主义者（又名某人像 Mark Seemann）的方法非常可行。

这样的框架倾向于使这成为可能，因为框架本身利用了（喘息！！！）服务定位器模式。不幸的是，在像 WPF 这样的平台上使用 MVVM 设计并不那么容易，因为在内置服务定位器的帮助下，您的视图并不总是从根目录提供。

但是，我确实有一个 ShellViewModel，它负责显示我需要的大部分视图，因此我认为这里最实用的答案是将我的 ShellViewModel 视为组合根的一部分并扩展我对 DI 的依赖容器放入其中。

除了我的 ShellViewModel 之外，我相信 500 的答案是正确的。

【讨论】：