我的模型应该长什么样？

Question

当我深入研究MVVM和MVVM-light时，我发现没有为模型提供MVVM-light基类。

但是从我的理解来看，消息传递和通知也可以在模型中发生。至少在模型之间的通信中，我会发现消息传递非常方便。

因此，我决定将我的模型派生自ViewModelBase，即使其中一些属性（如设计时属性）将不被使用。

但是我越看越觉得我错过了什么。从派生我的模型自ViewModelBase是否被认为是“不良实践”？

并且在模型通信中使用消息传递是否可以？

- Marcus Riemer

Answer 1

从任何你喜欢的地方派生你的视图模型类... MVVM-light提供了VieWModelBase来提供ICleanUp的实现 - 这对于管理ViewModel对象的生命周期很有用。我的选择是在一个基类中实现所有属性更改通知的脚手架，然后从那个模型类派生出来。关于模型类，我唯一强烈建议的是：

1. 一种尺寸并不适合所有情况。您存储数据的方式可能与您与数据交互的方式不同，ViewModel对象应该支持交互，而不是存储。如果您需要以两种非常不同的方式与相同的数据（模型）进行交互，则设计两个不同的ViewModel来支持这些不同的交互。

2. 使用属性（如System.ComponentModel）注释模型。您可以通过这种方式完成大部分验证工作，并且验证反馈是表示层（View + ViewModel）的责任，而不是问题域（即模型）的责任。

真正好的ViewModel类通常也足够无状态，可以在单个用户交互中被回收/重复使用，以便虚拟化大型数据列表（WPF支持虚拟化）以节省RAM。

记住DRY（不要重复自己），KISS（保持简单，愚蠢！）和YAGNI（你不会需要它）- 这些原则应该放在任何学术设计原则的前面。我曾经在实现学术上完美的MVC / MVVM模式的WPF应用程序上浪费了几周时间，结果发现它们削弱了最终解决方案的整体可理解性。所以...保持简单！ :)

- Mark

---

尽管这是一个非常好的答案，但它并没有完全回答我的问题。我的考虑主要是关于模型之间的通信和最佳实践。 - Marcus Riemer

我在一个WPF应用程序上实现了学术上完美的MVC/MVVM模式，浪费了几周时间，结果发现它们削弱了最终解决方案的整体可理解性。这正是我在MVVM学习曲线上所处的位置——这种认识。我想知道，你能否详细说明一下第二点？也许可以举个例子说明你做了什么以及它如何帮助你？ - bufferz

Answer 2

我建议您查看组合应用程序库中的EventAggregator。在这篇文章中，有一个很好的描述。Jeremy Miller的博客对此进行了更详细的阐述。

- SwDevMan81

---

那是否意味着我必须放弃MVVM-light并选择Prism？我还没有完全决定使用哪个MVVM框架，所以转换是可能的。 - Marcus Riemer

这取决于你，你可以下载代码（Prism）并查看它。如果你想走其他路线，那么你只需要学习你需要的课程。在我看来，我会使用组合应用程序库并使用MVVM模型。 - SwDevMan81