我正在为某些表单构建工作流程，这些工作流程将路由到用户进行审批。我有一个抽象的'FormBase'类，它存储一个'Approver'对象的LinkedList，并有一些帮助者修改批准者列表，将表单移动到下一个人，依此类推。这些帮助程序都是“虚拟”的，因此给定的表单可以使用自定义行为覆盖它们。
从这个'基础'将出现各种形式的实例，每个形式的数据都不同。它将是您在普通表单中找到的常规列表，字符串和数值。所以我可能有
class MaterialForm : FormBase
class CustomerForm : FormBase
等，当用户创建并提交表单时，会创建一个新实例。
我想以灵活的方式坚持EF6（或5）中的字段细节，这样我就可以创建更多来自FormBase的表单，而不会有太多的烦恼。理想情况下，我希望特定于该表单类型的所有行为都存在于MaterialForm派生类中。我想我不能将这个派生类持久保存到EF（除非我错了！）。我在考虑：
a）对字段详细信息进行JSonified，并将它们作为字符串存储在存储到EF的类中。我可能会对审批者列表做同样的事情，每次我需要修改列表时我都会将它们拉出来，修改列表并推回它们。
b）在我的抽象类中包含一个'FormData'属性，然后在每个具体实现中包含它的派生版本（例如MaterialFormData，CustomerFormData）。但是，抽象类似乎不喜欢以这种方式使用派生类型。还不清楚在这种情况下如何设置DbSets，因为您可能需要为每种类型设置一个新表。
我觉得我误解了关于“真正的”类如何与存储在EF中的类相关的基本信息。作为这种情况的架构，您会推荐什么？
答案 0 :(得分：2)
当涉及到Entity Framework时，您有三个支持的继承模型：Table Per Type（TPT），Table Per Hierarchy（TPH）和Table Per Concrete Class（TPC）。
通常避免使用TPC，而在其他两个之间进行选择可归结为几个因素，包括性能和灵活性。有一篇很好的文章概述了差异here。
我还建议您阅读this和this，了解有关这些模式如何运作的更多信息和示例。
但是，在您的示例中，就为您的应用提供合适的“模型”而言，问题似乎处于“设计”阶段。我的建议是，如果你觉得你提出的类结构不能准确地代表你正在使用的模型，你要么需要改变结构;你的模型非常复杂;或者您受到外部系统的限制（例如，您无法更改的数据库模式）。
在这种情况下，你考虑过做一个类图吗？即使您使用EF设计器，也要尝试可视化模型，因为这通常是确定可以进行改进的最佳方式，并且还为您提供了良好的设计开端（特别是如果您首先要编写代码）。 / p>
试试，如果有必要，请将其发回。如果需要，我们可以帮助重新设计模型。我的感觉是，几乎总有一些很好的方式用一个体面的OO视角来表示你的需求，最好在查看更精细的选项之前对其进行分析！这里的关键是避免在可以避免的情况下动态创建新的类类型。