asp.net-mvc - 将一个实体映射到一个视图模型或多个视图模型

Question

我有一个客户实体的多个视图模型，具体取决于创建、更新、获取、删除等现有视图。这些视图模型与实体共享高达 75% 的相同属性。

我是否应该更好地将所有客户视图模型合并到一个大视图模型中？

所以我只需要并且总是从一个实体映射到一个视图模型并返回吗？对于我现在没有想到的某些场景，您是否认为灵活性有任何劣势？

Answer 1

另一个，最适合您的 OO 选项在于良好的旧继承：在一个类中定义操作之间的通用功能，MyVM并根据您认为适合不同操作的方式扩展它（从它继承）：、、、、MyVMEdit“ MyVMList”。MyVMDeleteMyVMCreate

这是两全其美的：您只需维护一次，然后扩展它们以精确地适应每个视图。

这里没有正确的方法，因为它不是数学，所以你采取的任何完成工作的方法都会完成工作:)但是......有时我们离我们的根源太远了:)它纯粹的好旧的面向对象方法.

如果继承（或扩展）带来任何问题（出于任何原因），您可以MyVM在每个MyVM<Action>模型中嵌入部分并实现相同级别的抽象/功能平衡。

像往常一样 - 正确工作的正确工具。

希望这会帮助你。

Answer 2

一方面，按照您的描述拆分 ViewModel 可以使您的代码库非常清晰，因为您可以确保每个 ViewModel 都完全适合用途并且没有不必要的属性。另一方面，这意味着您需要维护更多代码 - 对实体的更改很可能意味着对多个 ViewModel 的更改。

另一方面，一个大的 ViewModel 方法基本上具有完全相反的优点和缺点 - 需要维护的代码更少，但 ViewModel 不太适合目的。

这里没有真正的正确或错误答案，您必须权衡每种方法的利弊，并决定哪种方法最适合您。

一种中途方法是使用一个 ViewModel 用于创建/更新，一个用于检索，一个用于删除，因为创建/更新可能非常相似。

Answer 3

从长远来看，将它们分开会更好，因为虽然每个 ViewModel 中包含的数据可能相似甚至相同，但意图是不同的。例如， Create 和 Update ViewModels 肯定是相似的，但有一些重要的区别。首先，创建视图模型通常没有实体的身份，并且拥有它可能会令人困惑，因为它没有意义。其次，如果应用程序支持部分更新，则更新的 ViewModel 可能是对现有实体的更改集合，而不是整个实体。

如果您正在努力实现DRY，则可以通过共享整个 ViewModel 类以外的方式实现可重用性。相反，您可以创建更小的可重用组件，并通过组合而不是继承来重用。试图强制单个 ViewModel 类来满足所有要求将是错误的，因为代码更难以推理。很多时候，简单的复制和粘贴比 OOP 提供的工作做得更好。