Блог

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

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

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

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

Я многому научился из блога г-на Манави. Особенно, наследование с помощью первой серии code-first было для меня полным новых вещей. В этой ссылке MSDN также есть несколько ценных ссылок / информации о различных сценариях сопоставления. Кроме того, я изучил материал manu, следуя или отвечая на вопросы с entity-framework тегами здесь, на SO.

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

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

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

Самые продвинутые функции, которые вы получите с помощью EF fluent-API или designer, это:

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

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

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

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

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

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

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

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