我正在阅读Mark Seeman的书“.NET中的依赖注入”。在其中，他描述了一个适配器类型，用于为视图提供适当的视图模型，但在相同的上下文中还提到使视图模型知道视图（尽管像IWindow之类的东西）来“控制其窗口环境，例如显示模态对话框。“
根据我的经验，这是对MVVM设计的一个非平凡的破坏，甚至可能是一个糟糕的DI解决方案。大多数这些“需求”通常能够通过DataTriggers，第三方服务，中介模式以及在某些情况下普通的旧clr事件的组合来表达。 （值得注意的是，许多人更喜欢通过IObserver注入暴露类似事件的ViewModel元素。Mark Seeman even blogged on this!
因此我问这个问题：“无论框架，技术，语言，堆栈或工具集如何。如果MVVM可以实现，是否（应该有）任何理由视图模型需要意识到查看？“
跟进相关问题：“由于严格执行模式的复杂性，是否有理由忽视此指南？”
答案 0 :(得分：3)
无论框架，技术，语言，堆栈或工具集如何。如果 MVVM可以实现，是否（应该有）任何原因 视图模型需要了解视图吗？
ViewModel是View的模型，而不是相反的模型，因此ViewModel中的View不应该有任何意识（直接或通过接口）。我唯一一次看到ViewModel应该让我们知道View，这是因为糟糕的设计。
是否有理由忽视此指导原因 严格执行模式的复杂性？
我认为没有。
许多ViewModel看起来好像开发人员在代码隐藏中首先完成了所有操作，然后将所有代码隐藏逻辑移到一个单独的类中，并将其称为ViewModel。你会看到那里的东西，比如打开弹出窗口或决定某个控件应该有多宽。
我认为这不是从MVVM中获得最大收益的方法。 UI逻辑将始终链接到View。如果您使用WPF或Silverlight，则很难摆脱代码隐藏中的所有代码。
E.g。显示模态对话框不是ViewModel的责任，它是决定如何表示某个条件/事件的UI。条件/事件可以在ViewModel中找到，但对此的更改将由View处理。