MVVM，我应该把逻辑放在模型或视图模型中（控制器）

Question

我是MVVM的新手，现在在Silverlight项目上做一些MVVM重构工作，假设它是一本书购物应用程序。

View是一个书籍列表，我将书籍的标题绑定到ViewModel。所以我在ViewModel中有public string Title { get; set; }，在模型中也是public string Title { get; set; }（我是对的吗？）

现在我想放一个事件处理程序来更新书名，我应该把事件处理程序放在ViewModel还是Model中？什么是模型用于？

Answer 1

在我看来“两者都不是”......而是将控制器类添加到MVVM的混合中。

将控制器代码放入视图模型中的问题是，使它们难以独立测试。在许多方面，我认为这与背后的代码一样糟糕。

在我看来，每个人都认为MVVM没有控制器，因为他们忽略了C. MVVM实际上是MVC的一种变体“只是添加了ViewModels”。

也许它应该被称为MVCVM？

ViewModels仅用于从视图中卸载“GUI”代码并包含任何用于绑定的数据。 ViewModels不应该进行任何处理。一个很好的测试是，您的ViewModel可以通过自动化单元测试进行测试，并且不依赖于数据源等。他们应该不知道数据实际来自哪里（或谁在显示它）。

虽然可以忽略/避免，但Controller应负责决定显示哪些数据模型以及在哪些视图中显示。 ViewModel是Models（MVVM中的M）和Views之间的桥梁。这允许更简单的“分离”XAML创作。

我们在所有最近项目中成功使用的模式是仅在模块中注册控制器，并在启动时初始化它们。控制器非常轻薄，是唯一需要在应用程序监听或发送消息的过程中闲逛的东西。在他们的初始化方法中，他们然后注册他们需要拥有的任何东西（视图和视图模型等）。这种轻量级逻辑内存模式也可以实现更轻薄的应用程序（例如WP7更好）。

我们遵循的基本规则是：

• 控制人员根据事件做出决定
• 控制器获取数据并将其放入适当的视图模型属性
• 控制器将View Models的ICommand属性设置为拦截 事件
• 控制器会显示视图（如果未在其他地方暗示）
• 查看模型是“愚蠢的”。他们持有绑定数据而没有其他内容
• 视图知道它们显示某种形状的数据，但不知道 它来自哪里

最后两点是你永远不应该打破的，或者关注点的分离会消失。

Answer 2

简单来说，模型是“真正的”底层数据模型 - 包含应用程序可能需要的书单的所有信息，能够从数据库中获取和设置数据。

ViewModel是一个主要用于为View提供数据绑定的对象。它可能是模型的子集，也可能将多个模型的属性组合到单个对象中。它应包含必要且足够的属性，以允许View执行其工作。

如果事件处理程序与View相关，则它属于ViewModel。如果符合您的目的，您可以尝试使用命令模式（请参阅Custom WPF command pattern example）。