Мы выставляем мэппинг для поля таблицы PostId в переменную Id. Сразу возникает вопрос, а где это мы успели определить переменную Id для таблицы BlogPost. Как я говорил раньше ANEF считает что у Entity Post и BlogPost есть только один ключ, поэтому неявно пририсовала его к таблице BlogPost. В итоге, наша конечная Entity выглядит так:
У нас есть две таблицы: BlogPost и Post. В таблицах есть два ключа BlogPost.PostId и Post.Id, так считает SQL. ANEF достаточно верно считает, что на самом деле, у таблицы BlogPost нет ключа BlogPost.PostId, а есть ключ Post.Id. В принципе это более чем логично, у нас есть связь 1:1, так зачем нам надо заморачиваться с ещё одним ключём? Тоже верно. Удаляем из Entity BlogPost параметр PostId. После этого валидация снова рушится. Тоже правильно. У нас в таблице есть значение PostId, но оно не имеет никаких мэппингов. Исправляем этот недочёт:
И вот тут я в первый раз словил разочарование от визуальной среды разработки. Запускаем валидацию проекта (я рекомендую запускать эту валидацию чуть ли не после каждого чиха, если вы ещё не совсем освоились в работе с наследованием ANEF). И валидация с треском падает. Неприятность заключается в том, что нам надо ещё немного пошаманить и кое что понять, прежде чем нам удастся нормально организовать наследование.
Заходим в студию, в наш проект базы данных и обновляем нашу схему из БД. При этом должна появиться новая Entity BlogPost. Всё отлично, появилась. Даже со связью. Удаляйте эту связь первым делом. В наследованных Entity она нам не нужна. После этого в контекстном меню Entity Post мы добавляем новое наследование. Выходит что-то типа этого:
Вот на этом скриншоте приведены правильные расстановки связей в БД. В первый раз, я по глупости развернул их в другую сторону, тобишь я сделал таблицу BlogPost Primary в связи. Ладно, бывает, поехали дальше.
Сразу оговорюсь. Здесь я сделал самую большую свою ошибку, которая стоила мне 20-ти минут работы с форумами. А в общем-то она была очень глупой, и была сделана по недосмотру.
Так же, мне было бы удобно, чтобы в моей модели БД были и простые User'ы и Admin'ы. Посему, используя поле IsAdmin я буду делать второй тип наследования одна таблица на несколько Entity. По значению в этом поле будет происходить отсеивание entity
Я создал таблицу BlogPost. Смысл этого в том, что в моей системе Post будет является не только постом блога, но и комментарием, сообщением, и вообще всем, что один пользователь может передать другому. Такая схема сделана исключительно для целей обучения. Потому что в большинстве систем комментарии это очень критичная таблица, в которой постоянно много записей, и которая является самой нагруженной таблицей в системе. Соответственно, BlogPost должен унаследовать все данные из Post и нести в себе дополнительную информацию. Я хочу, чтобы в моей системе под каждым постом блога пользователи сами писали название ссылки на комментарии. Например: «Жгут здесь», «Об этом думают». Это внесёт некое разнообразие. Ну, что же, все мои желания хорошо видны на схеме БД. Тут я применю первый тип наследования каждая Entity имеет свою таблицу.
Со времён структура БД немного изменилась, но всё же осталась очень простой. Изначально в БД присутствовали только две таблицы: Post и User, сейчас схема была немного усложнена
Вот моя база данных.
Да, кстати, неявно договорились вот о чём: ANEF = ADO.NET Entity Framework
Скажу сразу. Я над кодом просидел час, разбирая те ошибки, которые у меня возникли во время создания этой статьи. И моя цель сейчас не только показать, как реализуется наследование в ANEF но и показать вам типовые ошибки, которых можно избежать.
Опять же, замечу, что я не буду углубляться в теорию, всё показываю на практике. Для теории я сделаю отдельный цикл статей.
В новой статье хотелось бы поговорить о наследовании. Признаться честно, до изучения ADO.NET Entity Framework я вообще даже не задумывался о том, чтобы вводить в свои проекты наследование сущностей в объектно-ориентированных обёртках для БД. Обычно базу строили так, чтобы максимально избегать наследования. Хотя, порой оно и маячило на горизонте, но обходилось. Сейчас я опишу, как я добавил в свой проект два очень простых класса, которые были отнаследованны от уже имеющихся таблиц.
Моя первая статья на хабре была оценена хабраюзерами достаточно высоко. Что же, спасибо всем кто оставил своё мнение о статье, мне было приятно вас почитать, я продолжаю.
Приветствую всех!
О чём вы, Морфеус?
Наследование в ADO.NET Entity Framework
20 декабря 2008 в 13:15
Наследование в ADO.NET Entity Framework / Хабрахабр
Комментариев нет:
Отправить комментарий