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

只是好奇。

假设我有一个Base实体，并且我使用Table Per Type方法从中派生出大约10个不同的子实体。 我还有一个通用的存储库，可以从每个子实体中获取数据。 我最终想要将每个子实体映射到一个单独的视图模型，并将每个视图模型链接到我自己网站上的自己的网格（JqGrid），每个网格都有自己的Create，Read，Update，Delete方法。 我可以做到这一切，但我不确定在将代码保持在最低限度的同时正确的方法是什么。

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

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

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

或者，对于每个网格，将这些操作分开是否更好？

嗯..

Answer 1

这取决于。

除了所有规则，我会说：保持简单，不要重复自己。

一些评论：

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

仅作为旁注：你知道TPT的表现不佳（至少EF <5），对吧？ 需要注意的是，特别是如果表可能很大或者您具有深层继承层次结构（从派生实体派生的实体......等）

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

在我看来，这是一个好主意，仅针对可能适用于每个派生实体的ViewModel的不同validation规则。

拥有“父”视图模型然后从中导出子视图模型以模仿实体的inheritance结构是否更好？

在我看来， 模仿实体的inheritance并不是一个原因。 但是，如果您有基本模型属性的视图validation规则，并且它们适用于所有派生实体，那么为什么不将这些规则保存在一个位置 – 就像基本ViewModel一样。 否则，您必须在每个派生的ViewModel中重复它们。

在这种情况下，每个视图模型是否应该有自己的一组CRUD操作？

如果派生实体是“平面”（仅具有标量属性且没有导航属性），则只需要以下内容：

Read: context.BaseEntities.OfType().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。

我应该使用reflection吗？

WTF？ 为什么？ 最好不要。

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

??? （< - 这应该是一个“困惑的”-Emoticon）