Entity framework - хранение различных типов

Question

Я создаю рабочий процесс для некоторых форм, которые будут направляться пользователям на утверждение. У меня есть абстрактный класс «FormBase», в котором хранятся объекты LinkedList «Approver» и есть некоторые помощники, которые изменяют список утверждений, переносят форму на следующего человека и так далее. Эти помощники являются «виртуальными», поэтому данная форма может переопределять их с помощью пользовательского поведения.

От этой «базы» появятся экземпляры различных форм, каждый из которых будет отличаться в данных, которые он содержит. Это будет обычный набор списков, строк и числовых значений, которые вы найдете в обычной форме. Поэтому у меня может возникнуть

class MaterialForm : FormBase 
class CustomerForm : FormBase 

и т. Д., А новый экземпляр создается, когда пользователь создает и отправляет форму.

Я хотел бы сохранить детали поля в EF6 (или 5) гибким способом, чтобы я мог создавать больше форм, происходящих из FormBase, без излишней вопли. В идеале я хотел бы, чтобы все поведение, характерное для этого типа формы, предназначалось для жизни в производном классе MaterialForm. Я полагаю, что я не могу перенести этот производный класс на EF (если я не ошибаюсь!). Я рассматриваю:

a) JSonifying детали поля и сохранение их как строки в классе, который хранится в EF. Я бы, вероятно, сделал то же самое для списка утверждений, и каждый раз, когда мне нужно изменить список, я бы вытащил их, изменил список и оттолкнул их.

b) Включая свойство «FormData» в моем абстрактном классе, затем включающее производную версию этого в каждой конкретной реализации (например, MaterialFormData, CustomerFormData). Однако абстрактному классу не понравилось мое использование производного типа таким образом. Также неясно, как настроить DbSets в этом случае, поскольку вам, вероятно, понадобится новая таблица для каждого типа.

Я чувствую, что не понимаю, что такое фундаментальные понятия о том, как «реальные» классы относятся к тем, которые хранятся в EF. Что бы вы рекомендовали в качестве архитектуры для этого случая?

Answer 1

Когда речь заходит о Entity Framework, у вас есть три поддерживаемые модели для наследования: таблица на тип (TPT), таблица на иерархию (TPH) и таблица на конкретный класс (TPC).

Использование TPC обычно исключается, и выбор между двумя другими способами сводится к нескольким факторам, включая производительность и гибкость. Существует отличная статья, в которой изложены различия here.

Я также рекомендую прочитать this и this для получения дополнительной информации и примеров того, как эти шаблоны работают.

Тем не менее, в вашем примере это звучит так, как будто проблема находится на стадии «дизайна» с точки зрения разработки подходящей «модели» для вашего приложения. Мой совет заключается в том, что если вы чувствуете, что структура классов, которую вы создали, не может точно представить модель, с которой вы работаете, вам либо нужно изменить структуру; ваша модель очень сложна; или вы ограничены внешней системой (схема базы данных, которую вы не можете изменить, например).

В этом случае, рассмотрели ли вы схему классов? Даже если вы используете конструктор EF, попробуйте и визуализируйте модель, так как обычно это лучший способ определить, где можно сделать улучшения, а также дать вам хорошее начало в дизайне (особенно если вы сначала начнете код).

Попробуйте это, и отправьте это здесь, если необходимо. Затем мы можем помочь перепроектировать модель, если потребуется.Я чувствую, что почти всегда есть хороший способ представить ваше требование с достойной перспективой OO, и лучше проанализировать это, прежде чем смотреть на более сложные варианты! Ключ здесь заключается в том, чтобы не думать о том, чтобы создавать новые типы классов динамически, если этого можно избежать.