对于一个客户实体，我有多个视图模型，取决于现有的视图，如Create、Update、Get、Delete。这些视图模型与实体共享高达75%的相同属性。
我应该更好地将所有客户视图模型合并为一个大视图模型吗？
所以我只需要始终从一个实体映射到一个视图模型，然后返回？对于我现在没有想到的某些场景，你认为灵活性有什么缺点吗？
从长远来看，将它们分开会更好，因为虽然每个ViewModel中包含的数据可能相似甚至相同，但意图不同。例如，创建和更新视图模型当然是相似的，但有一些重要的区别。首先，创建视图模型通常没有实体的标识，将其放在那里可能会令人困惑，因为它没有意义。其次，如果应用程序支持部分更新，则更新ViewModel可能是对现有实体的更改的集合，而不是整个实体。
如果您正在努力实现DRY，您可以通过共享整个ViewModel类以外的其他方式来实现可重用性。相反，您可以创建更小的可重用组件，并通过组合而不是继承进行重用。试图强制一个ViewModel类来满足所有需求将是有缺陷的，因为代码更难推理。很多时候，简单的复制&粘贴比OOP提供的更好地完成工作。
一方面，按照您的描述拆分ViewModel会使您的代码库非常清晰，因为您可以确保每个ViewModel都完全适合用途，并且没有不必要的属性。另一方面，这意味着您需要维护更多的代码——对实体的更改很可能意味着对几个ViewModel的更改。
另一方面，一种大型ViewModel方法的优点和缺点基本上完全相反——需要维护的代码较少，但ViewModel不太适合使用。
这里并没有一个正确或错误的答案，你必须权衡每种方法的利弊，并决定什么最适合你。
一种折中的方法是使用一个ViewModel来创建/更新、一个用于检索和一个用于删除，因为创建/更新可能非常相似。
另一个最适合您的OO选项在于良好的旧继承：在一个类MyVM中的操作之间定义通用功能，并根据您认为适合不同操作的情况对其进行扩展（从中继承）：MyVMEdit、MyVMDelete、MyVMCreate、`MyVMList'。
这是两全其美的：你只维护一次东西，然后扩展它们以精确地适应每个视图。
这里没有正确的方法，因为这不是数学，你采取的任何方法都会完成任务：）但是有时我们离我们的根太远了：）它是一种纯粹好的旧面向对象方法。
如果继承（或扩展）带来了任何问题（出于任何原因），您可以在每个MyVM<Action>模型中嵌入MyVM部分，并实现相同级别的抽象/功能平衡。
像往常一样-适合正确工作的正确工具。
希望这对你有帮助。