在MVVM中ViewModel的真正目的是什么？

Question

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

更新 我同意将VM和模型混合为单个.cs数据模型和数据转换规则，以便在View中表示它。但如果这只是一个好处 - 我不想为每个View创建一个VM。

那么你知道VM的专业是什么？

Answer 1

他有什么约束力？无论你绑定什么，实际上都是一个视图模型，无论你是否称之为。如果它也兼作数据模型，那么您违反了单一责任委托人（SRP）。从本质上讲，问题在于您将代码应用于应用程序体系结构的不同部分，这将导致复杂的混乱。

Answer 2

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

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

因此，视图有一个角色，模型有一个角色，VM是那些之间的逻辑。

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

Answer 3

UI测试是一种痛苦，不仅因为您需要适应View中的更改，这些更改可能会多次发生，而且因为UI会干扰自己的测试。根据所需的测试，您需要跟踪焦点，调整大小以及可能非常难以使其成为代表性测试的其他（鼠标）事件。

将测试范围扩展到ViewModel中的逻辑并将UI测试留给人类要容易得多。人类测试人员不需要测试逻辑;他们唯一的安慰应该是用户界面。

通过将ViewModel分解为ViewModel的层次结构，您可以多次重用ViewModel。没有规则声明您应该为每个View设置ViewModel。 （在一两个版本之后，我结束了，但除了这一点之外:)）

Answer 4

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