Entity Framework - mapping (часть 2)

Продолжение. Начало здесь

Один класс - несколько EntitySet.

Еще один интересный вариант маппинга один класс – несколько таблиц, когда все таблицы имеют одинаковую структуру. В терминах EF это называется multiple entity sets per type (MEST). Рассмотрим пример БД:



БД содержит две таблицы одинаковой структуры для хранения каких-то запросов. Поскольку запросов много, для хранения текущих запросов используется таблица Request, а устаревшие и обработанные запросы переносятся в таблицу RequestHistory.

Если создать EDM визардом, мы получим две идентичные сущности Request и RequestHistory, и два соответствующих им EntitySet. Согласитесь это не очень удобно. Вот если бы EntitySet Request и RequestHistory остались, но оба использовали один и тот-же тип сущности. И это можно сделать. Однако нам придется опять расстаться с дизайнером, поскольку он не поддерживает такой вариант маппинга.

Итак, закрываем дизайнер и открываем edmx файл в XML редакторе. Изменяем описание EntitySet RequestHistory, чтобы он использовал класс Entity вместо EntityHistory:

<EntityContainer Name="MultiSet">
 <EntitySet Name="Request" EntityType="MultiSetModel.Request" />
 <EntitySet Name="RequestHistory" EntityType="MultiSetModel.Request" />
</EntityContainer>

Затем удаляем описание сущности RequestHistory (<EntityType Name="RequestHistory">).

Наконец правим маппинг EntitySet RequestHistory, заменяем тип RequestHistory на Request (измененное выделено):

<EntitySetMapping Name="RequestHistory">
 <EntityTypeMapping TypeName="IsTypeOf(MultiSetModel.Request)">
  <MappingFragment StoreEntitySet="RequestHistory">
   <ScalarProperty Name="Id" ColumnName="Id" />
   <ScalarProperty Name="IncomDate" ColumnName="IncomDate" />
   <ScalarProperty Name="Text" ColumnName="Text" />
   <ScalarProperty Name="AcceptDate" ColumnName="AcceptDate" />
  </MappingFragment>
 </EntityTypeMapping>
</EntitySetMapping>    

Вот собственно и все. Теперь класс Request используется при запросах к обеим коллекциям (и дизайнер не может открыть нашу модель).

Маппинг на хранимые процедуры

Многие спрашивают, поддерживает ли EF при маппинге классов хранимые процедуры? Для любителей маппинга на хранимые процедуры у меня две новости, хорошая и плохая. Хорошая состоит в том, что маппинг сущностей на хранимые процедуры в EF есть. Плохая – полностью отказаться от использования запросов в маппинге не возможно. Использовать хранимые процедуры в маппинге сущностей можно для операций вставки, обновления и удаления. В EF beta3 эти возможности уже поддерживаются дизайнером EDM. Однако для выборки все равно нужен маппинг на таблицы или view.

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

Создадим таблицу Category с двумя полями Id (первичный ключ) и Title:

CREATE TABLE Category(
 Id int IDENTITY(1,1) NOT NULL,
 Title nvarchar(50) NOT NULL,
 CONSTRAINT PK_Category PRIMARY KEY CLUSTERED (Id ASC)

Обратите внимание, что ключевое поле Id объявлено как IDENTITY, это повлияет на некоторые детали маппинга.

Далее нам необходимо создать три хранимые процедуры для вставки, обновления и удаления записей в таблице Category:

CREATE PROCEDURE [dbo].[CreateCategory] 
 @Title nvarchar(50)AS
BEGIN
 INSERT INTO [Category] ([Title])
    VALUES(@Title)

 SELECT [Id] from [Category] where @@ROWCOUNT > 0 and [Id] = scope_identity()
END

CREATE PROCEDURE [dbo].[UpdateCategory] 
@Id int, 
@Title nvarchar(50)AS
BEGIN
 UPDATE [Category]
    SET [Title] = @Title 
    WHERE [Id] = @Id
END

CREATE PROCEDURE [dbo].[DeleteCategory] 
@Id int as
BEGIN
 DELETE [Category]
    WHERE [Id] = @Id
END

Из-за того, что столбец Id у нас объявлен как Identity, в процедуру CreateCategory передается только один параметр @Title, иначе надо было бы передавать еще и @Id. По этой же причине в процедуре присутствует select, который возвращает значение Id только что добавленной строки. И наконец, по этой же причине, в процедуре UpdateCategory параметр @Id используется исключительно для поиска нужной записи.

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

Теперь займемся маппингом. В левом углу панели «Mapping details» есть две кнопки, которые переключают режим работы панели: «Map Entity to Tables / Views» и «Map Entity to Functions». До сих пор мы пользовались только первым режимом. Теперь нам надо переключиться на второй:



В пустой панели предлагается выбрать три функции для Insert, Update и Delete. Выбираем функции в выпадающих списках. Затем мапим параметры. Для функции CreateCategory необходимо выполнить Result Column Bindings. Для этого на месте надписи <Add Result Binding> вводим «Id» и мапим его на свойство Id. Таким образом, EF сможет получать значение Id вставленной записи.

Для параметров функции Update мы видим флажки «Use Original Value». При помощи этого флажка мы говорим, что EF должен взять оригинальное, а не измененное значение поля Id и передать его в функцию UpdateCategory. Почему так, я думаю, вы сами догадались.

Остается добавить, что «Result Column Bindings» есть и для функции Update. В нашем случае он не используется. Однако можно представить себе ситуацию, когда хранимая процедура не только сохраняет переданные в параметрах значения в БД, но руководствуясь какой-то своей логикой, еще и изменяет их. В этом случае новые значения можно вернуть через «Result Column Binding». Это, конечно, кошмарный сценарий, но в жизни бывает всякое.

Не стоит забывать, что привычный маппинг сущности Category на соответствующую таблицу никуда не делся. Достаточно переключить режим отображения панели маппинга:



Избавиться от него не получится. EF для выборок будет использовать только его. Единственное, что можно сделать, это заменить таблицу на view.

Ассоциация «многие ко многим»

Все мы знаем, что объектная ассоциация многие ко многим в реляционных структурах реализуется посредством промежуточной таблицы и двух ассоциаций «один ко многим». Вот я и решил посмотреть, как с этой задачей справится EF. Для этого я сделал вот такую БД с клиническим классическим примером «студенты – курсы»:



После работы визарда получилась вот такая EDM модель:



В общем, и сказать то больше не чего. Пробовал я и тренарные ассоциации (это когда в StudentCourseMap добавляем еще один внешний ключ на третью таблицу), в этом случае в модели появляется еще один класс.

Заключение

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

Среди обнаруженных недостатков можно выделить следующие:

• при маппинге столбцов необходимо устанавливать соответствие свойству и нельзя вместо свойства использовать константу


• нет способа запретить создание навигационных свойств на одном из концов ассоциации.


• нет возможности маппировать класс только на хранимые процедуры без использования таблиц и view.


• не все возможности маппинга поддерживаются дизайнером EDM.