2

我正在为某些表单构建一个工作流，该工作流将路由给用户以供批准。我有一个抽象的“FormBase”类，它存储一个“审批者”对象的 LinkedList，并有一些帮助者修改审批者列表，将表单移动到下一个人等等。这些助手都是“虚拟的”，因此给定的表单可以用自定义行为覆盖它们。

从这个“基础”中会出现各种形式的实例，每一种形式所包含的数据都会有所不同。它将是您在正常形式中找到的正常列表、字符串和数值的集合。所以我可能有

 class MaterialForm : FormBase
 class CustomerForm : FormBase

等等，当用户创建并提交表单时，会创建一个新实例。

我想以灵活的方式保留 EF6（或 5）中的字段详细信息，这样我就可以创建更多从 FormBase 派生的表单，而无需太多摆弄。理想情况下，我希望特定于该表单类型的所有行为都存在于 MaterialForm 派生类中。我想我不能将这个派生类持久化到 EF（除非我错了！）。我正在考虑：

a）JSonifying字段详细信息，并将它们作为字符串存储在存储到EF的类中。我可能会为批准者列表做同样的事情，每次我需要修改列表时，我都会将它们拉出，修改列表并将它们推回。

b) 在我的抽象类中包含一个“FormData”属性，然后在每个具体实现中包含该属性的派生版本（例如 MaterialFormData、CustomerFormData）。但是，抽象类似乎不喜欢我以这种方式使用派生类型。同样不清楚的是在这种情况下如何设置 DbSet，因为您可能需要为每种类型创建一个新表。

我觉得我误解了一些关于“真实”类与存储在 EF 中的类之间的关系的基本知识。对于这种情况，您会推荐什么架构？

4

1 回答 1

2

对于实体框架，您有三种受支持的继承模型：每个类型的表 (TPT)、每个层次结构的表 (TPH) 和每个具体类的表 (TPC)。

通常避免使用 TPC，而在其他两者之间进行选择归结为几个因素，包括性能和灵活性。有一篇很棒的文章概述了这里的差异。

我还建议阅读此和此，以获取有关这些模式如何工作的更多信息和示例。

但是，在您的示例中，就为您的应用程序提出合适的“模型”而言，问题似乎处于“设计”阶段。我的建议是，如果你觉得你想出的类结构不能准确地代表你正在使用的模型，你要么需要改变结构；要么 您的模型非常复杂；或者您受到外部系统的约束（例如，您无法更改的数据库模式）。

在这种情况下，您是否考虑过做一个类图？即使您使用 EF 设计器，也请尝试对模型进行可视化，因为这通常是确定可以在哪些方面进行改进的最佳方式，并且还可以为您提供良好的设计开端（尤其是在您先编写代码的情况下）。

尝试一下，如有必要，将其发回此处。如果需要，我们可以帮助重新设计模型。我的感觉是，几乎总是有一些好的方法可以用一个体面的 OO 视角来表达您的需求，最好在查看更详细的选项之前分析它！这里的关键是避免考虑动态创建新的类类型，如果可以避免的话。

于 2013-07-13T08:01:42.510 回答