Question

好奇。

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

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

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

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

或者，为每个网格分别保持这些操作是否更好？

嗯..

Answer 1

取决于。

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

一些意见：

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

仅作为旁注：您知道TPT的表现不佳（至少对于EF <5），对吧？特别是如果表可能很大或者您有一个深层继承层次结构（从派生实体派生的实体......等），请记住这一点。

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

在我看来，这是一个好主意，仅针对可能适用于每个派生实体的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？为什么？最好不要。

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

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

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

1 个答案: