使用 EF/Code First/Repository Pattern/Table Per Type (TPT) 时的良好编程原则？

Question

只是好奇。

假设我有一个 Base 实体，我使用 Table Per Type 方法从中派生了大约 10 个不同的子实体。我还有一个通用存储库，可以从每个子实体中获取数据。我最终想将每个子实体映射到一个单独的视图模型，并将每个视图模型链接到我网站上自己的网格（JqGrid），每个网格都有自己的创建、读取、更新、删除方法。我可以做到所有这些，但我不确定在保持代码最少的同时，正确的方法是什么。

现在，我在每个视图模型中都定义了每个字段（来自父实体和子实体）。拥有一个“父”视图模型然后从中派生子视图模型以模仿实体的继承结构是否更好？我不这么认为....在视图模型中继承对我来说没有多大意义。

另外，我真的不想为每个网格重复 CRUD 操作。这被认为是好的做法吗？在这种情况下，每个视图模型是否应该有自己的一组 CRUD 操作？

以“阅读”为例。我基本上是根据每个网格的视图模型的 ID（键）字段返回 JSON 数据。并且由于所有网格都将具有此 ID 列（父实体的一部分），我是否应该只有一个函数来处理所有网格？我应该使用反射吗？我应该使用父/子实体的多态属性吗？

还是让每个网格的这些操作分开更好？

嗯嗯..

Answer 1

视情况而定。

在所有规则之上，我想说：保持简单，不要重复自己。

一些cmets：

假设我有一个 Base 实体，我正在派生大约 10 个不同的子实体 使用 Table Per Type 方法从中提取实体。

仅作为旁注：您知道 TPT 的性能不佳（至少对于 EF

我最终想将每个子实体映射到单独的视图 型号

在我看来，这是一个好主意，单独用于可能的不同验证规则，您可以将其应用于每个派生实体的 ViewModel。

有一个“父”视图模型然后派生孩子会更好吗 从中查看模型，以模仿 实体？

模仿在我看来，实体的继承不是一个原因。但是，例如，如果您在基本模型属性上查看验证规则并且它们适用于所有派生实体，为什么不将这些规则保存在一个地方 - 就像基本 ViewModel 一样。否则，您必须在每个派生的 ViewModel 中重复它们。

每个视图模型是否应该有自己的一组 CRUD 操作？ 案例？

如果派生实体是“扁平的”（只有标量属性而没有导航属性），您只需要类似以下内容：

Read: context.BaseEntities.OfType<T>().Where(...)...
Add: context.BaseEntities.Add(T entity);
Delete: context.BaseEntities.Remove(T entity);
Update: context.Entry(object o).State = EntityState.Modified;

所有这些方法都适用于基础实体和派生实体。为什么要为每个实体分别创建这样的方法？尽管在更复杂的情况下，您可能需要单独的方法，例如，如果派生实体编号 7 具有到另一个实体的导航属性，并且您对该实体的视图确实允许更改与另一个实体的关系。所以，这取决于。我不会从复制所有功能相同的方法开始，而是稍后在我看到我需要特殊处理时进行重构（除非您可能从一开始就预见到在项目发展过程中的某个时间点需要特殊处理）。

我基本上是根据 ID（键）字段返回 JSON 数据 每个网格的视图模型。而且由于所有网格都将具有此 ID 列 （父实体的一部分），我应该只有一个功能 为所有网格处理这个？

在存储库/服务方面，是的，只要为每个派生实体加载标量属性。如果您需要派生实体 7 的导航属性，您可能需要一些特殊的东西（可能是 Include）。将数据投影到 ViewModel 中可能特定于每个实体，因为每个实体都有单独的 ViewModel。

我应该使用反射吗？

WTF？为什么？最好不要。

我应该利用父/子的多态属性吗 实体？

？？？ （