2

只是好奇。

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

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

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

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

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

嗯..

4

1 回答 1

4

这取决于。

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

一些评论：

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

仅作为旁注：您知道 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。

我应该使用反射吗？

怎么回事？为什么？最好不要。

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

？？？（<-这应该是一个“困惑”-表情）

于 2012-11-08T19:09:22.843 回答