silverlight - MVVM，我应该将逻辑放在模型还是 View 模型( Controller )中

Question

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

View 是一个书籍列表，我将书籍的标题绑定(bind)到 ViewModel。所以我有一个 public string Title { get;放; } 在 ViewModel 中，也是一个 public string Title { get;放; } in‖模型(我说的对吗？)

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

Answer 1

在我看来“两者都不是”...改为将 Controller 类添加到 MVVM 的组合中。

将 Controller 代码放在 View 模型中的问题在于，这使得它们更难独立测试。在很多方面，我认为这与隐藏代码一样糟糕。

在我看来，每个人都假设 MVVM 没有 Controller ，因为他们省略了 C。MVVM 实际上是 MVC 的变体，“它只是添加了 ViewModels”。

也许它应该被称为 MVCVM？

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

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

我们在所有近期项目中成功使用的模式是仅在模块中注册 Controller ，并在启动时初始化它们。 Controller 非常轻/薄，是应用程序生命周期中唯一需要卡在身边的东西，用于收听或发送消息。在他们的初始化方法中，他们然后注册他们需要拥有的任何东西( View 和 View 模型等)。这种轻量级逻辑仅在内存中的模式也使应用程序更 slim (例如，更适合 WP7)。

我们遵循的基本规则是:

• Controller 根据事件做出决定
• Controller 获取数据并将其放置在适当的 View 模型属性中
• Controller 设置 View 模型的 ICommand 属性以拦截 事件
• Controller 使 View 出现(如果其他地方没有暗示)
• View 模型是“愚蠢的”。他们只保存绑定(bind)数据
• Views 知道它们显示特定形状的数据，但不知道 它来自哪里

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