Любые приличные ресурсы о том, как отобразить сложные объекты POCO в EF 4.1?

Question

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

Прочитав много похвал за EF 4.1, я решил провести технико-экономическое обоснование. Я обнаружил, что EF 4.1 - зверь, чтобы творить свою голову. Это невероятно сложно с сотнями способов сделать то же самое. Кажется, это работает нормально, если вы планируете использовать простые сопоставленные сущности таблица-объект, но сложное сопоставление объектов POCO было настоящей PITA. Хороших учебников нет, а те, что существуют, очень зачаточны.

Существуют тонны блогов об изучении основ EF 4.1, но у меня есть ощущение, что они намеренно избегают сложных тем. Есть ли хорошие уроки по более сложным картографическим сценариям? Например, взять существующий объект POCO и отобразить его на несколько таблиц или сохранить объект POCO, состоящий из других объектов POCO? Я продолжаю слышать, что это возможно, но не нашел никаких примеров.

Answer 1

Отказ от ответственности: IMO EF 4.1 наиболее известен своим подходом Code-First.Большинство следующих ссылок указывают на статьи о том, как делать вещи в стиле кода.Я не очень знаком с подходами DB-First или Model-First.

Я многому научился у Мистер.Блог Манави .В частности, Наследование с серией код-первых было для меня новым. Эта ссылка MSDN также содержит несколько ценных ссылок / сведений о различных сценариях сопоставления.Кроме того, я изучил материал manu, следуя или отвечая на вопросы с тегами entity-framework здесь, на SO.

Всякий раз, когда я хочу попробовать какое-то новое отображение сложных объектов, я прилагаю все усилия (основываясь на моих знаниях об EF), чтобы создать правильные отображения;Однако иногда вы сталкиваетесь с тупиком.Вот почему Бог создал StackOverflow.:)

Answer 2

Что вы подразумеваете под EFv4.1?Вы имеете в виду перегруженный code-first / fluent-API?В таком случае приходится жить с фактом, что это в основном для простых сценариев картирования.Он предлагает больше, чем L2S, но все еще очень мало с точки зрения продвинутых отображений.

Базовое отображение, доступное в EF, следует базовому правилу: одна таблица = одна сущность.Сущность может быть отдельным классом или составом основного класса, представляющего саму сущность и вспомогательные классы для набора сопоставленных полей (сложных типов).

Наиболее продвинутые функции, которые вы получите с EF fluent-API или конструктором:

• Наследование TPH - несколько таблиц в иерархии наследования, сопоставленных одной и той же таблице.Типы отличаются специальным столбцом, называемым дискриминатором.Общие поля должны находиться в родительском классе.
• Наследование TPT - каждый тип сопоставляется с отдельной таблицей = базовый тип имеет одну таблицу, а каждый производный тип также имеет одну таблицу.Общие поля должны быть определены в базовом типе и, следовательно, в базовой таблице.Отношение между базой и производной таблицей является взаимно-однозначным.Производные объекты охватывают несколько таблиц.
• Наследование TPC - у каждого класса есть отдельная таблица = общие поля должны быть определены в базовом типе, но каждый производный тип имеет их в своей собственной таблице.
• Разделение сущности - сущность разбивается на две или более таблицы, которые связаны отношением один-к-одному.Все части сущности должны существовать.
• Разделение таблицы - таблица разбивается на две или более сущностей, связанных с отношением «один к одному».

Дизайнер также предлагает

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

При использовании таблицы базовых или более сложных функций может участвовать только одно сопоставление.

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

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

• Определение запроса - пользовательский запрос SQL, используемый для указания загрузки новой «сущности».Этот подход также изначально используется EDMX и дизайнером при отображении представления базы данных
• Представление запроса - настраиваемый запрос ESQL, используемый для указания нового "объекта" из уже отображенных объектов.Он более удобен для предопределенных проекций, поскольку в отличие от определения запроса он имеет некоторые ограничения (например, агрегации не допускаются).

Обе эти функции позволяют определять классы, объединенные из нескольких таблиц.Недостатком обоих этих методов сопоставления является то, что сопоставленный результат доступен только для чтения.Вы должны использовать хранимые процедуры для сохранения изменений при использовании этих методов.