我的模型应该是什么样子？答案

【问题标题】：How should my model look like?我的模型应该是什么样子？
【发布时间】：2010-08-31 11:47:32
【问题描述】：

当我进一步深入研究 MVVM 和 MVVM-light 时，我认识到，没有为模型提供 MVVM-light 基类。

但据我了解，消息传递和发出通知也可能发生在模型中。至少在模型之间的通信中，我会发现消息传递会非常方便。

所以我决定从 ViewModelBase 派生我的模型，即使某些属性（如设计时属性）将不会被使用。

但是我越看这个，我就越觉得我错过了什么。从 ViewModelBase 派生我的模型是否被认为是“不好的做法”？

可以使用 Messaging 进行模型通信吗？

【问题讨论】：

标签： c# wpf design-patterns mvvm-light

【解决方案1】：

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

一旦尺寸不适合所有人。您存储数据的方式可能与您与数据交互的方式不同，ViewModel 对象应该面向支持交互而不是存储，如果您需要以两种截然不同的方式与相同的数据（模型）进行交互，那么设计两个不同的 ViewModel 来支持这些不同的交互。
请使用属性（类似于 System.ComponentModel）来注释模型。您可以通过这种方式完成大量验证工作 - 验证反馈是表示层（View + ViewModel）的责任，而不是问题域（即模型）的责任。

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

记住 DRY（不要重复自己）、KISS（保持简单，愚蠢！）和 YAGNI（你不会需要它） - 是您应该牢记的原则高于任何学术设计原则。我实际上已经在 WPF 应用程序上浪费了数周时间来实现学术上完美的 MVC/MVVM 模式，结果却发现它们降低了最终解决方案的整体可理解性。所以...保持简单！ :)

【讨论】：

虽然这是一个很好的答案，但并不完全符合我的问题。我的考虑主要是关于模型之间的通信和模型的最佳实践。
“我确实在 WPF 应用程序上浪费了数周时间来实现学术上完美的 MVC/MVVM 模式，结果却发现它们降低了最终解决方案的整体可理解性。”这正是我的 MVVM 学习曲线所处的位置——这种认识。我想知道，您能否详细说明第 2 点。也许是你所做的事情以及它如何帮助你的例子？

【解决方案2】：

我会看看Composite Application Library 中的EventAggregator。 this 帖子中的答案对此进行了很好的描述。 Jeremy Miller 的post 更详细。

【讨论】：

这是否意味着我必须放弃 MVVM-light 并选择 Prism？我还没有决定 100% 的 MVVM 框架，所以切换是可能的。
这取决于你，你当然可以下载代码（Prism）并检查一下。如果你想走其他路线，那么你可以参加你需要的课程。 IMO，我会使用复合应用程序库并使用 MVVM 模型。