Entity Framework: множественное наследование

Question

Хорошо, очевидно, я борюсь с .net здесь ... и ответ, вероятно, заключается в том, что я лаю не на том дереве и должен просто продолжать использовать тот тип проектирования баз данных, который я использовал бы 5 лет назад.

Я хочу иметь абстрактный объект «Клиент» и иметь 2 унаследованных объекта «Поставщик и клиент».

Отношение между клиентом и поставщиком, и клиентом составляет 1: 0/1

ЭтоПохоже, что это означает, что решение, основанное на наследовании, будет работать хорошо, так как оно позволит мне писать меньше проверочного кода, а также будет управлять строго типизированными коллекциями.клиентская таблица и отказ от предоставления вам одинакового идентификатора, на который ссылаются таблицы клиента и поставщика.

когда вы входите в базу данных и редактируете этот идентификатор вручную, чтобы он был одинаковым для обоих унаследованных объектов, вы получаете проблемы, потому чтоКоллекция клиентов имеет индекс столкновения (не задумываясь).

В результате у меня не может быть клиента, который выступает в роли как поставщика, так и клиента (меня порадовала идея о двух отдельных объектах с одинаковым идентификатором).

Это приводит к вопросу о том, как лучше всего работать.смоделируйте этот сценарий ... Мне грозит необходимость условного соединения и логических полей для 'isCustomer', 'isSupplier' или таблицы поставщиков и клиентов, которая присоединяется к клиенту и пишет код для поддержания отношения 0-1 сэто.

Кто-то еще должен был иметь такого рода проблемы?Нет элегантных решений?

альтернатива: мне нужно несколько видов одного и того же объекта.Это означает, что я не могу просто иметь целочисленное значение в одном поле, определяющее, какие виды разрешены.Мне нужно использовать несколько полей bool, чтобы определить, какие виды объектов разрешены.

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

Answer 1

К сожалению, то, что вы просите, на самом деле не возможно..NET не допускает множественного наследования, поэтому это не является (и не будет) функцией EF или любого другого ORM.

Вам придется удалить наследование в конструкторе EF ипросто допустите нормальную связь 1: 1 * между таблицами.

В итоге вы получите нужный вам дизайн базы данных, и ваш синтаксис C # будет выглядеть так:

Client c;

c.Customer.[...]
c.Supplier.[...]

Answer 2

Я знаю этот пост, если 5 лет EF все еще не исправили это ...

Возможно, я что-то упускаю, но EF не позволит нескольким детям наследовать от одного из родителей, а DotNetвполне способен на это.Я могу обойти это, изменив каждую сущность на частичный класс, а затем определив интерфейс, который реализует каждый частичный класс.Это нелепо.Каждая таблица в нашей базе данных имеет 4 столбца: CreatedBy, CreatedOn, updatedBy, updatedOn.Если я создаю абстрактный класс в структуре сущностей, я должен иметь возможность наследовать каждую сущность от этого одного абстрактного класса, чтобы каждая сущность имела эти четыре поля.Но ты не можешь.Только одна таблица может наследоваться от абстрактного класса.Это не имеет никакого смысла.Это побеждает цель абстрактного класса вообще.Я хочу, чтобы каждая сущность шла с этими четырьмя полями, но только один ребенок может иметь их.Корпорация должна иметь эти четыре поля.Учреждения, являющиеся дочерними частями корпорации, также должны иметь эти четыре поля.Но нет, не могу этого сделать.Несмотря на то, что TimeStampTable является абстрактным классом, только одна таблица может наследовать, и только одна таблица получает четыре поля

Вот диаграмма сущностей

..... в любом случае, я чувствую твою боль, и есть работа вокруг.создайте интерфейс, который вы хотите, измените ваши сущности на частичные классы, затем в отдельном файле для каждой сущности наследуйте частичные классы от этого интерфейса,

вы должны реализовать этот интерфейс вручную в каждом файле частичных классов.

Удачи (или найдите другой ORM)

Answer 3

Поместите все, что является общим для клиентов и поставщиков, в клиент, и только вещи, специфичные для клиентов в клиенте, вещи, специфичные для поставщиков в поставщике.

3 таблицы, 3 вида объектов.