Как я могу добавить наследование к объекту, определенному в EntityDataModel (EF 4)?

Вот твоя проблема:

У меня есть тестовый пример для этого сценария, где система находит человека, которого она хочет превратить в пользователя.

Объекты не могут изменять типы в C # или любом другом OOPL на основе классов, о котором я знаю. EF этого не меняет.

Вам нужно изменить свой дизайн. Это не ОО. Я писал об этом в прошлом году:

Один из ментальных барьеров, который вы должны преодолеть при разработке хорошего объектно-реляционного сопоставления, - это тенденция мыслить в первую очередь объектно-ориентированными терминами или терминами отношений, в зависимости от того, что подходит вашей личности. Однако хорошее объектно-реляционное сопоставление включает в себя как хорошую объектную модель, так и хорошую реляционную модель. Например, предположим, что у вас есть база данных с таблицей для людей и связанными таблицами для сотрудников и клиентов. У одного человека может быть запись во всех трех таблицах. Теперь, с чисто реляционной точки зрения, вы можете создать представление базы данных для сотрудников и еще одно для клиентов, причем оба они включают информацию из таблицы People. При использовании того или иного ВИДА вы можете временно думать об отдельном человеке как о «просто» сотруднике или «просто» о клиенте, даже если вы знаете, что они оба. Таким образом, у кого-то из этого мировоззрения может возникнуть соблазн сделать объектно-ориентированное отображение, в котором Employee и Customer являются (прямыми) подклассами Person. Но это не работает с имеющимися у нас данными; поскольку у одного человека есть записи и о сотруднике, и о клиенте (и поскольку ни один экземпляр Person не может одновременно относиться к конкретному подтипу Employee и Customer), объектно-ориентированные отношения между Person и Employee должны быть композиция, а не наследование, и то же самое для Person и Customer.

Мне удалось решить эту проблему, но я не совсем доволен решением. Я закончил тем, что написал хранимые процедуры для сопоставления операций вставки, обновления и удаления как для человека, так и для пользователя (поскольку они находятся в одном наборе сущностей, оба должны быть сопоставлены со всеми тремя sprocs). Спрок вставки для User принимает параметр PersonID и использует его, чтобы решить, создавать ли новую строку Person или присоединяться к существующей строке Person.

Загвоздка в том, что PersonID должен отображаться как входной параметр sproc и как привязка столбца результатов. Когда база данных должна сгенерировать новый PersonID, мы должны вернуть его, используя привязку результата, чтобы другие таблицы получили правильное значение для столбцов внешнего ключа, ссылающихся на PersonID. Кроме .... вы не можете сопоставить User.PersonID одновременно как входной параметр и привязку столбца результата. Это вызывает исключение времени выполнения «Невозможно определить допустимый порядок для зависимых операций. Зависимости могут существовать из-за ограничений внешнего ключа, требований модели или сохранения сгенерированных значений».

В итоге я добавил новый столбец в таблицу User (и в соответствующую концептуальную модель), который является обнуляемым int (я назвал его BasePK). В EDM я сделал геттеры и сеттеры для этого свойства защищенными, чтобы скрыть их от общедоступного интерфейса. Затем я сопоставил BasePK как входной параметр sproc и сопоставил PersonID как привязку столбца результата, чтобы получить значение идентификатора, если оно было сгенерировано. Одна перегрузка для конструктора User выглядит следующим образом:

общедоступный пользователь (int personID): base () {this.BasePK = personID; }

Итак, теперь, когда я хочу превратить существующего человека в пользователя, мне просто нужно создать пользователя, используя эту перегрузку.

int personID = [какой-то метод поиска человека и возврата его / ее PersonID]; var User = новый пользователь (personID);

Когда ObjectContext вставляет сущность, он передает PersonID в sproc через свойство BasePK. Когда sproc завершен, он возвращает PersonID фактическому свойству первичного ключа.

Мне не понравилась идея добавления столбца и свойства для этого, но она действительно сочетается с моим комментарием к ответу Крейга: я хочу иметь возможность подключаться к Person с новыми специализациями без необходимости изменять / перекомпоновывать Person сущность каждый раз. Таким образом, по крайней мере, я могу сохранить все изменения в типах производных сущностей, даже если это означает, что эти изменения включают добавление бессмысленных столбцов, которые всегда будут иметь значение NULL в физическом хранилище.