承認のためにユーザーにルーティングするいくつかのフォームのワークフローを構築しています。「承認者」オブジェクトの LinkedList を格納する抽象「FormBase」クラスがあり、承認者リストを変更したり、フォームを次の人に移動したりするヘルパーがあります。これらのヘルパーはすべて「仮想」であるため、特定のフォームがカスタム動作でそれらをオーバーライドできます。
この「ベース」からさまざまなフォームのインスタンスが生成され、それぞれに含まれるデータが異なります。通常の形式で見られるリスト、文字列、および数値の通常のセットになります。だから私は持っているかもしれません
class MaterialForm : FormBase
class CustomerForm : FormBase
ユーザーがフォームを作成して送信すると、新しいインスタンスが作成されます。
EF6 (または 5) のフィールドの詳細を柔軟な方法で保持したいので、あまりいじることなく FormBase から派生するフォームをさらに作成できます。理想的には、そのフォーム タイプに固有のすべての動作が MaterialForm 派生クラスに存在することを望みます。この派生クラスを EF に保持することはできないと思います (間違っていない限り!)。私は考えています：
a）フィールドの詳細をJSon化し、EFに保存されるクラスに文字列として保存します。おそらく承認者リストについても同じことをし、リストを変更する必要があるたびに、承認者を引き出し、リストを変更し、元に戻します。
b) 'FormData' プロパティを抽象クラスに含め、その派生バージョンを各具象実装 (MaterialFormData、CustomerFormData など) に含めます。しかし、抽象クラスは、このように派生型を使用することを気に入らなかったようです。また、この場合、タイプごとに新しいテーブルが必要になる可能性があるため、DbSets がどのようにセットアップされるかは不明です。
「実際の」クラスが EF に格納されているクラスとどのように関係しているかについて、根本的なことを誤解しているように感じます。この場合のアーキテクチャとして何をお勧めしますか?