MVVM，我应该将逻辑放在模型还是视图模型（控制器）中答案

【问题标题】：MVVM, should I put logic in model or view-model (controller)MVVM，我应该将逻辑放在模型还是视图模型（控制器）中
【发布时间】：2011-10-17 02:05:49
【问题描述】：

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

View 是一个书单，我将书名绑定到 ViewModel。所以我在 ViewModel 中有一个public string Title { get; set; }，在Model 中也有一个public string Title { get; set; }（对吗？）

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

【问题讨论】：

标签： silverlight model-view-controller mvvm

【解决方案1】：

在我看来“两者都没有”... 将控制器类添加到 MVVM 的组合中。

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

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

也许它应该被称为 MVCVM？

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

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

我们在最近的所有项目中成功使用的模式是仅在模块中注册控制器，并在启动时对其进行初始化。控制器非常轻巧/纤薄，是应用程序在监听或发送消息的整个生命周期中唯一需要保留的东西。然后在他们的初始化方法中注册他们需要拥有的任何东西（视图和视图模型等）。这种轻量级的仅内存逻辑模式也使应用程序更轻薄（例如，更适合 WP7）。

我们遵循的基本规则是：

控制器根据事件做出决策
控制器获取数据并将其放置在适当的视图模型属性中
控制器将视图模型的 ICommand 属性设置为拦截活动
控制器使视图出现（如果其他地方没有暗示）
视图模型是“愚蠢的”。它们保存用于绑定的数据，仅此而已
视图知道它们显示某种形状的数据，但不知道它来自哪里

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

【讨论】：

关于是否在 ViewModel 中放置事件处理或逻辑可能存在争议，但现在我想知道 Model 专用于什么？它不应该有逻辑吗？
模型包含业务数据（通常是业务逻辑，但从不包含 UI 或应用程序逻辑）。它的模型永远不应该知道它是如何被消耗的。
在 MVVM 中（这还存在吗？）应该不需要控制器。 View 直接绑定到 ViewModel。 ViewModel 提供跨“实际”模型的抽象。您通常在 Controller 中执行的任何操作都应在 ViewModel（数据抽象）或 View 本身（操作和交互）中完成。
@KirkBroadhurst：虽然这是可能的，但这与我建议的更好方法完全相反。您的建议很常见，但更难测试并将代码与演示文稿或数据模型紧密耦合。

【解决方案2】：

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

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

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

【讨论】：