我有一些关于MVVM模式的问题

哇,我会尽量回答你的问题,这些问题不涉及具体的技术或框架,尽可能…对不起,如果我错过了一些(要点会有帮助)

• MVVM不一定是MVP的变体。MVP本身是一个不明确的、已加载的术语。马丁·福勒公正地做到了 splitting it into two patterns . MVVM独立存在,但与MVP模式共享一些概念。与所有的UI模式一样,它试图尽可能地将视图逻辑与业务逻辑分开。MVVM与MVP的不同之处在于,它创建的模型纯粹是为了表示(或 presentation model )这与MVP模式解决分离问题的方式不同。
  • Passive View -对于被动视图,视图永远不会看到模型。
  • Supervising Controller -与被动视图相比,MVVM更接近于监控控制器模式。这里唯一的区别可能是MVVM仅为视图显式地创建了一个模型(因此术语“视图模型”)。
• 视图模型没有对视图的引用,因为它用作视图数据的模型。这是一个适当的抽象。如果它也引用了视图,那么您将拥有一个双向依赖关系,这将创建额外的耦合。而且,视图模型本身没有真正的理由去了解视图。它的唯一工作是从视图中抽象模型(实际业务模型)。
• delegatecommands和relaycommands——我相信你在这里得到了特定的技术,所以我不能很好地回答这个问题。
• 不应为多个视图设计视图模型。这只会造成复杂性,因为如果更改视图,则必须调查哪些视图模型可能会受到影响并更改这些视图模型。这可能导致级联效应。您的行为应该在业务模型中,而不是视图模型中,因此视图模型只需要包含转换和事件处理逻辑。
• 不过,最好是将ViewModel与UserControl的比例设为1:1,因为用户控件应该能够在屏幕上充当自治单元。
• 至于其他技术方面的问题,对不起,我没有答案。不过,我建议您仔细阅读我为 被动观 , 监控控制器 和 Presentation Model . 为UI模式提供一些上下文,并且是技术中立的。

需要记住的是,虽然MVVM适合于解决采用WPF所带来的问题,但它不是特定于技术的模式。如果您在不理解基础哲学的情况下过于深入地研究特定的实现,那么您可能会在早期犯一些非常大的错误,并且只有在为时已晚之后才发现它们。不幸的是,MVVM不是一个有良好文档记录的模式,当您声明每个人都对它有自己的想法时,您是对的。

这不是一个革命性的模式(它已经存在了很多年,名字不同),但是WPF的数据绑定使得它现在成为一个可行的解决方案,因此它正在获得新的流行。这是一个 好的 模式,但这不是理论。对待你所面对的每一个“命令”都要有适当数量的怀疑。

编辑

@micahtan 当声明数据绑定是WPF中非常重要的部分时是正确的。我说过,WPF的数据绑定支持MVVM解决方案,但是绑定本身非常强大,这就是为什么MVVM的采用比它周围的文献增长更快的原因。

实际上你不必使用relaycommand。您真正需要做的就是在对象上实现ICommand接口。在 SoapBox Core 框架I定义了一个名为ICommandControl的接口,以及所有按钮视图模型等,实现了这个接口。还有一个 AbstractCommandControl 可以从中派生以实现它的类。