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