6

我与 teamlead 讨论过这个话题，从他的角度来看，我们可以只使用绑定和命令省略 ViewModel，因为我们可以使用自动化或我们自己开发的 UI 测试机制（基于对视图的自动点击）在没有 VM 的情况下测试 UI 行为）。那么，如果没有真正的好处，我为什么要产生“冗余”实体？此外，自动化集成测试看起来比 VM 测试更具指示性。因此，似乎我们可以混合使用 VM 和模型。

更新： 我同意混合 VM 和模型将数据模型和数据转换规则带入单个 .cs 以在视图中表示它。但如果这只是一个好处——我不想为每个视图创建一个虚拟机。

那么你知道VM的哪些优点？

4

4 回答 4

6

VM 是 UI 背后的逻辑。至少从我的经验来看，将 UI 代码与逻辑相结合最终会变得一团糟。您的视图应该定义您所看到的 - 按钮、菜单等。您的 VM 负责绑定和处理由用户引起的事件。

编辑：
不想为每个视图创建 VM 听起来不像是面向软件的原因。这样做将使您的视图逻辑清晰，并且您的模型可以自由地成为核心层和应用程序层之间的连接层。
我喜欢下面提到模型及其角色的示例（为什么它不应该与 VM 结合使用）：假设您正在使用 Google 地图开发一些 Android 应用程序。谷歌地图是你的核心。然后有一天，您真的需要选择将地图的某些部分涂成粉红色、亮粉红色。向 Google 索要的电子邮件colorPink(Map)可能会让您无处可去。这就是您的模型介入并为您提供定义小指方法所需的地图包装器的地方。
如果没有单独的模型，您将不得不检查每个使用map并更新它的 VM。

所以，视图有一个角色，模型有一个角色，VM 是它们之间的逻辑。

编辑 2：
在某些情况下不需要模型层——我起初倾向于不同意，但在讨论后被说服了：在相对较小的应用程序中，模型最终可能成为一个冗余包装器，核心没有附加功能. 在这种情况下，您可以直接使用核心对象。

于 2013-07-16T05:58:49.210 回答
4

他要绑定什么？他绑定的任何东西实际上都是一个视图模型，不管你是否这样称呼它。如果它还兼作数据模型，那么您就违反了单一责任原则 (SRP)。本质上，这里的问题是您将服务于应用程序架构不同部分的代码混为一谈，这将导致混乱。

于 2013-07-16T05:46:57.860 回答
1

UI 测试很痛苦，不仅因为您需要适应视图中可能发生多次的更改，还因为 UI 往往会干扰其自身的测试。根据所需的测试，您需要跟踪焦点、调整大小和可能的其他（鼠标）事件，这很难使其成为具有代表性的测试。

将测试范围限定在 ViewModel 中的逻辑并将 UI 测试留给人类要容易得多。人工测试人员不需要测试逻辑；他们唯一的问题应该是用户界面。

通过将 ViewModel 分解为 ViewModel 的层次结构，您可能能够多次重用 ViewModel。没有规则规定您应该为每个 View 拥有一个 ViewModel。（一两次发布后，我最终到了那里，但这不是重点:)）

于 2013-07-16T07:25:17.363 回答
0

这取决于您的模型的性质 - 有时它们很简单，并且可以像您建议的那样充当两者。但是，根据框架的不同，您需要使用一些 PropertyChanged 事件代码来弄脏您的模型，这可能会变得混乱和分散注意力。在更复杂的情况下，它们充当视图和模型之间的中介。假设您正在创建一个监控远程进程或数据库条目的客户端应用程序 - 为这些实体创建视图模型让您以一种方便绑定到 UI 框架的方式显示数据（但在 DB 框架中很愚蠢)，将操作封装为命令，执行验证等。

于 2013-07-16T05:59:49.820 回答