MVVM中各层的角色

Question

我知道在MVVM中，我们希望通过数据绑定将用户输入从视图传播到视图模型，并在查看模型到模型，我们编写业务逻辑代码，并通过事件用结果更新用户。
但是，是否意味着视图中的每个更改都必须在xaml.cs文件之外完成？
例如，sliding puzzle的WPF应用程序：
如果我们想编写一个算法来解决难题，我们将把代码放在模型中。
但是，假设我们想在用户单击向下键后更新网格。 检查是否可以进行此类移动，重新绘制棋盘或给予玩家任何反馈（如果移动是合法的还是没有）应该在视图中完成？ （xaml.cs文件）
更一般地说，是否有＆＃34;经验法则＆＃34;决定在哪里处理？

Answer 1

快速回顾一下MVVM层（或“经验法则”）：

• 模型：仅包含视图模型使用的数据。作为示例，请将来自数据库的业务对象视为“模型”。
• 查看：用户与视图模型之间的连接。您可以对同一视图模型使用多个视图。如果视图模型更改并更新，则视图应显示更改。
• ViewModel ：包含视图和模型之间的“业务逻辑”。因此，命令，可能的动作和算法存储在此处。视图模型决定了什么是可能的，什么不是。

层之间的通信需要（这是MVVM所必需的部分）可互换，这意味着视图模型可以与不同的兼容性视图一起使用，并且该模型可以由不同的兼容性视图模型使用。要减少多个图层的依赖关系：图层不应直接在它们之间进行通信。我们使用命令，事件和直接绑定。

  

但是，是否意味着视图中的每个更改都必须在xaml.cs文件之外完成？ [...]但是，假设我们想在用户点击向下键后更新网格。检查是否可以进行此类移动，重新绘制棋盘或给予玩家任何反馈（如果移动是合法的还是没有）应该在视图中完成？ （xaml.cs文件）

没有。视图模型应该明确地告诉视图哪些是可能的，哪些是不可能的。该视图显示该操作是否可行：如果可能，它不会决定。这样的决定是在业务逻辑中，因此在视图模型中。

作为思考的一部分，请理解可互换的视图。如果您为另一个视图foo切换视图bar以显示您的拼图，并且您确实在视图中做出了“可能有什么”的决定，那么您将不得不重写决策树/算法。新视图bar，因此，重复代码/逻辑。

当决定更高时，视图会反映视图模型告诉他的内容。如果视图模型希望视图“刷新”或告诉用户“嘿，这是非法移动”，视图模型将通过commands和事件来完成。收到此类事件后，视图可以决定如何处理它：

• 显示有关非法移动的错误消息
• 显示移动非法的工具提示
• 用哔哔声闪烁并摇动窗口以显示移动是非法的
• 更多实施......

我希望尽可能彻底地回答你的问题。

Answer 2

我的10美分：

如果我的经历教会了我什么，那么用相同的一般解决方案来解决所有问题几乎是不可能的。

在MVVM的情况下，我学到了一些东西（困难的方法）：

1. 视图模型很容易转换为上帝类（即混合纯视图相关逻辑+某些业务逻辑+等等。）
2. 根据应用程序层，有时候逻辑在视图模型上工作是有意义的;其他时候，更好的逻辑是在模型上工作。
3. 无论我/你/任何人认为某些类/逻辑应该去哪个层，都很可能必须随着开发的进展而改变。

相反，我的做法通常是：

1. 准备
   • 模型（用于序列化，非常少的逻辑），
   • 查看模型（具有视图的属性更改绑定）和
   • 查看（薄层，几乎直接绑定到View Model）
2. 在View Model中编写大部分应用程序逻辑。
   • 此处更容易拥有逻辑，因此视图绑定可以正常工作
   • 这是视图模型层膨胀的阶段

3. 当应用程序最终运行时，开始重构

   1. 对于富客户端应用程序，我发现我的Model类几乎是纯粹的数据

   2. 视图模型最有可能被重构为2层：MVM（模型 - 视图 - 模型）和VVM（视图模型）

      • MVM：这是与业务相关的常见逻辑/对象所在的地方
      • MVM对象包含任何视图可以绑定到
      的真正常见属性
      • VVM：这几乎是WPF视图的一对一复制
      • 这些对象通常不会在自己的视图之外共享
      • 分离到MVM和VVM有助于防止单个视图模型类适应任何视图。需要（即整个Is(Selected|Checked|etc)和*Command，只能由一个视图使用）。
      • （对于某些人来说，VVM逻辑可能是View的一部分。但对我而言，我经常发现自己最终希望我先把它们分开来进行测试。所以现在我做了。）

   3. 随着应用程序的发展，属性/方法可以从MVM推送到VVM，反之亦然。

      • 应用程序的层次结构几乎从不是真正的静态。
      • 即使您可以构建最佳版本的应用程序，客户端也只需要更多。

拥有重构现有架构以满足新要求的专有技术＆gt;设计一个足够灵活的架构，以满足未来的任何需求

说了这么多，对于许多不太复杂的应用程序，略微凸起的View模型通常都足够好。