Сразу оговорюсь, какое отношение имеет цикл статей про Entity Framework к веб-программированию. В дальнейшем я собираюсь использовать полученную модель для создания веб-приложения на базе технологии ASP.NET MVC 3, которая очень хорошо сочетается с Entity Framework.

Прежде всего - вам нужно иметь установленную Visual Studio 2010 (кажется 2008 тоже подойдет) и установленный пакет ADO.NET Entity Framework 4.1 найдите его по ссылке или в поиске на microsoft.com. Теперь нам становятся доступны все возможности ADO.NET Entity Framework. Замечу, что четвертая версия отличается от более ранних, так что, если у вас установлена более ранняя версия, то не гарантирую, что у вас будет работать тот код, что я привел в статье.

Итак, создаем обычное консольное приложение. Присваиваем ему имя test1. Добавляем в проект модель данных. Add -> New Item... -> ADO.NET Entity Data Model, называем ее MyEFModel.edmx.

Среда разработки предлагает нам два варианта создания модели: генерация из базы данных и пустую модель. В этой статье мы собираемся рассмотреть принцип Model First, то есть начинать разработку мы будет с создания модели данных, из которой впоследствии будет сгенерирована схема данных (таблицы и связи в базе данных). А это значит, что мы выберем вариант создания пустой модели Empty Model. После этого перед нами откроется пустое поле дизайнера модели данных. Если дизайнер не открылся, то сделайте двойной клик на модели MyEFModel.edmx в Solution Explorer'е.

Итак, мы хотим спроектировать модель данных для проверки пользовательских прав на те или иные операции. А значит в модели данных у нас будут присутствовать следующие сущности: Пользователь (User), Группа (Group) и Право (Right). Каждый пользователь обязательно принадлежит какой либо группе, и при этом строго одной. Каждая группа содержит в себе несколько прав, или не содержит ни одного. Все просто - при регистрации нового пользователя создается одна сущность User, у которой есть свойство Group, привязывающее пользователя к конкретной группе пользователей(например, администраторы, модераторы, авторы, читатели, посетители). Группа в нашем случае это набор прав (таких как: "блокирует пользователя", "редактирует чужую статью", "создает статью", "читает статью" и т.д.).

Перед тем как создавать сущности, давайте скажем дизайнеру модели, по каким правилам будут формироваться имена коллекций сущностей. Я вот о чем. Одновременно с сущностью в модели создается также контейнер этих сущностей, то есть по сути коллекция. Аналогия с таблицей в БД прямая: сущность - это строка в таблице, контейнер сущностей - сама таблица. Дизайнер дает имя контейнеру исходя из имени сущности (имя контейнера, впрочем, всегда можно поменять), и для сущности User, контейнер он может назвать UserSet или Users. По мне так название Users гораздо приятнее. А потому для самой модели в свойствах мы выставим Pluralize New Objects = True.

Итак, создаем сущности(сущности создаются правым кликом на диаграмме модели данных и выбором контекстного меню Add -> Entity...):

1. Entity Name = User Entity; Set = Users. Остальные свойства оставим без изменений. Заметим лишь, что по умолчанию дизайнер модели создает первичный ключ Id целочисленного типа, что для нас вполне приемлемо. Добавляем в эту сущность свойства(Properties):
   • Login (Type = String, Max Length = 255);
   • Registered (Type = DateTime).
   
   Свойства добавляются в контекстном меню самой сущности (Add -> Scalar Property).
2. Entity Name = Group; Entity Set = Groups. Свойства: Name (Type = String, Max Length = 255).
3. Entity Name = Right Entity; Set = Rights. Свойства: Description (Type = String, Max Length = 255).

1. Association Name = UserGroup; Начало: Entity = User, Multiplicity = Many; Конец: Entity = Group, Multiplicity = One. Это соотношения "Один ко многим", то есть каждый пользователь может состоять только в одной группе, но в каждой группе может быть много пользователей. (Если бы у сущности Group мы выбрали Multiplicity = Zero or One, то мы бы получили отношение "Один ко многим", но дали бы при этом возможность иметь пользователей не принадлежащих ни одной группе, то есть у пользователя свойство Group было бы Nullable).
2. Association Name = GroupRight; Начало: Entity = Group, Multiplicity = Many; Конец: Entity = Right, Multiplicity = Many. Это соотношение "Многие ко многим", то есть группа содержит в себе множество прав, при этом каждое право может принадлежать нескольким различным группам.

Вот какая схема данных у нас появилась: рисунок


Обратите внимание, что после создания связей, в каждой из сущностей появились дополнительные навигационные свойства. Например, свойство Group сущности User дает нам возможность узнать группу, в которой состоит пользователь, а свойство Rights сущности Group дает нам возможность получить список всех прав группы. Таким образом, обратившись к concreteUser.Group.Rights мы получим список прав пользователя. Как видно из схемы данных, среда разработки создала также и встречные (обратные) навигационные свойства Right.Groups и Group.Users.

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

Правый щелчок мыши на диаграмме, затем в контекстном меню "Generate Database from Model...". Здесь мы можем выбрать существующее подключение к БД или создать новое. Мы создадим новое подключение (кнопка New Connection...), здесь вы выбираете сервер БД, способ и параметры аутентификации, и имя базы данных (если хотите создать новую, то просто введите имя новой БД в поле Select or enter a database name), жмем OK. (Я создал базу EFUSERS на локальном компьютере). Мастер спросит вас нужно ли создать БД, вы соглашайтесь. После этого мы снова вернемся в мастер генерации БД, убедитесь, что галочка "Save entity connection settings in App.config as" установлена и нажмите Next. После этого во вкладке DDL мастер отобразит вам DDL-скрипт схемы данных. Здесь вы нажмите Finish.

После работы мастера мы получили следующее:

1. скрипт схемы данных в файле MyEFModel.edmx.sql,
2. строка подключения MyEFModelContainer в файле App.config (откройте его и посмотрите в раздел сonnectionStrings)
3. пока еще пустая база данных EFUSERS.

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

Теперь нам нужно выполнить DDL-крипт, чтобы создать все необходимые объекты в БД. Вы можете выполнить файл скрипта в Query Analizer, а можете сделать это прямо в Visual Studio, открыв скрипт и нажав кнопку Execute SQL в панели инструментов, или нажав комбинацию Ctrl+Shift+E. Студия запросит у вас параметры подключения к БД а затем выполнит скрипт. Открыв теперь базу в Enterprise Manager мы можем увидеть, что там создано 4 таблицы: Users, Rights, Groups, GroupRight. Первые три таблицы хранят в себе сущности трех видов, а вот четвертую Junction-таблицу (GroupRight) Entity Framework создал для того чтобы хранить отношения "Многие ко многим" между сущностями Group и Right. Как видим, при помощи подхода Model First мы полностью ушли от этапа проектирования таблиц в БД, всю работу Entity Framework сделал за нас. Обратим также внимание, что в таблице Users появилась колонка Group_Id ссылающаяся на группу, в которую входит пользователь, колонка эта NOT NULL, и это гарантирует что пользователь обязательно будет принадлежать той или иной группе. Ниже приведена схема БД, на которой отображены поля таблиц, первичные и внешние ключи.

Схема хранения данных: рисунок.


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

Я не буду приводить здесь DDL-скрипт, сгенерированный студией, но он доступен для ознакомления по ссылке MyEFModel.edmx

Ну вот, вся предварительная работа сделана, модель данных нарисована, схема данных создана, пустые таблицы в БД присутствуют. Осталось теперь попробовать поработать со всем этим добром.

Чтобы обратиться к данным в БД, нужно создать экземпляр контейнера модели. Класс контейнера называется MyEFModelContainer, инстанцируем его:

MyEFModelContainer cnt = 
  new MyEFModelContainer("name=MyEFModelContainer");

 В качестве аргумента конструктора мы задаем имя строки подключения к БД. Эта строка подключения представляет собой нечто большее, чем обычная ConnectionString для подключения к базе данных, потому что в нашем случае используется провайдер System.Data.EntityClient, которому для инициализации требуется гораздо больше параметров. Строка подключения была создана мастером ранее и хранится в файле App.config, строка подключения выглядит так:

provider=System.Data.SqlClient;
provider connection string="data source=.;initial catalog=EFUSERS;
integrated security=True;multipleactiveresultsets=True;App=EntityFramework"

Посмотрите внимательно, строка подключения имеет в себе три обязательных параметра: metadata, provider и provider connection string. Первый параметр задает ссылки на файлы CSDL, SSDL и MSL моделей. Все эти три файла хранятся в папке edmxResourcesToEmbed(найдите ее в дереве каталогов проекта) и представляют собой XML-файлы, описывающие соответственно: CSDL - концептуальную(объектную) модель в терминах бизнес-уровня, SSDL - схема хранения (реляционная схема), MSL - схема сопоставления (то есть связи между элементами CSDL и SSDL). Собственно все эти XML-файлы объединены в один с расширением EDMX.

Параметры provider и provider connection string задают как раз привычную нам строку подключения к БД.

Конструктор класса MyEFModelContainer можно вызвать также совсем без параметров, тогда по умолчанию строка подключения будет взята из App.config и станет равна той строке подключения, для которой собственно генерировался изначально DDL-скрипт.

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

Итак, теперь у нас есть контейнер данных, который помимо огромного количества прочих полезностей, содержит в себе три коллекции: Users, Groups, Rights - это те самые коллекции, ради которых собственно все и затевалось. Операции, производимые нами над этими коллекциями, автоматически (ну или почти автоматически) отображаются в базу данных, добавляя, удаляя или изменяя строки в соответствующих таблицах. Попытка чтения из коллекции приведет к выполнению SELECT-запроса к соответствующей таблице.

Пока наши таблицы пусты попробуем добавить в них некоторые данные. Пусть мы хотим, чтобы существовали два пользователя: chitatel и pushkin. Первый по статусу положено только чтение статей, второму - и чтение и запись. Понятно, что никаких статей у нас пока нет, важно только само разграничение прав на операции. При этом chitatel принадлежит группе "Читатели", а pushkin - группе "Писатели". Таким образом нам нужно создать два права: "Читать статьи" и "Редактировать статьи"; две группы: "Читатели" и "Писатели"; двух пользователей: chitatel и pushkin. А также - создать между ними корректные связи. Приведу сразу кусок кода, который надо выполнить единожды для того, чтобы создать все необходимые записи в таблицах.

// Создаем объекты прав
Right canRead = new Right()
{
  Description="Читать статьи",
};
Right canWrite = new Right()
{
  Description="Редактировать статьи",
};
// Создаем объекты групп
Group groupReaders = new Group()
{
  Name = "Читатели"
};
Group groupWriters = new Group()
{
  Name = "Писатели"
};
// Присваиваем группам соответствующие права
groupReaders.Rights.Add(canRead);  // читатели могут только читать
groupWriters.Rights.Add(canRead);  // писатели могут и читать
groupWriters.Rights.Add(canWrite); // и писать

// Создаем объекты пользователей и заносим их в соответствующую группу
User userChitatel = new User()
{
  Login = "chitatel",
  Registered = DateTime.Now,
  Group = groupReaders
};

User userPushkin = new User()
{
  Login = "pushkin",
  Registered = DateTime.Now,
  Group=groupWriters
};

// Теперь все эти существующие исключительно в памяти объекты
// добавляем в соответствующие коллекции контейнера
using (MyEFModelContainer cnt = 
  new MyEFModelContainer("name=MyEFModelContainer"))
{
  cnt.Rights.AddObject(canRead);
  cnt.Rights.AddObject(canWrite);
  cnt.Groups.AddObject(groupReaders);
  cnt.Groups.AddObject(groupWriters);
  cnt.Users.AddObject(userChitatel);
  cnt.Users.AddObject(userPushkin);
  // И финальный аккорд - сохраняем все изменения в БД
  cnt.SaveChanges();
}

Colored with dumpz.org

 После выполнения приведенного кода мы получим вот такие данные в таблицах: рисунок.

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

Для этого мы выполним следующий код:

            using (MyEFModelContainer cnt = 
                     new MyEFModelContainer("name=MyEFModelContainer"))
            {
                var check = from u in cnt.Users
                            where u.Login == "pushkin" && 
               u.Group.Rights.Any(f => f.Description == "Редактировать статьи")
                            select u;
                Console.WriteLine(check.Count());
            }

 Дословно, LINQ-запрос выбирает из БД всех пользователей, имеющих заданный логин(то есть единственного пользователя), и в правах группы в поле Description имеющих содержимое "Редактировать статьи". Если такой пользователь существует, то check.Count() == 1, а значит пользователь имеет требуемое право.

Текст SQL-запроса, выполненного в БД, выглядит так:

SELECT 
[GroupBy1].[A1] AS [C1]
FROM ( SELECT 
 COUNT(1) AS [A1]
 FROM [dbo].[Users] AS [Extent1]
 WHERE (N'pushkin' = [Extent1].[Login]) AND ( EXISTS (SELECT 
  1 AS [C1]
  FROM  [dbo].[GroupRight] AS [Extent2]
  INNER JOIN [dbo].[Rights] AS [Extent3] ON [Extent2].[Rights_Id] = [Extent3].[Id]
  WHERE (N'Редактировать статьи' = [Extent3].[Description]) AND ([Extent1].[Group_Id] = [Extent2].[Groups_Id])
 ))
)  AS [GroupBy1]

Colored with dumpz.org

 Здесь мы видим безобразный SELECT FROM SELECT отягощенный EXISTS-ом и INNER JOIN-ом. На мой взгляд, запрос далеко не оптимален. Немного упростить запрос, убрав из него INNER JOIN можно, если искать права не по названию ("Редактировать статьи"), что в любом случае являет плохим тоном, потому что зависит от способа написания названия права, а искать по Id права, ведь согласитесь сопоставление ID и DESCRIPTION в нашей базе всегда будет сохраняться. Таким образом, упрощаем LINQ-запрос:

var check = from u in cnt.Users
  where u.Login == "pushkin" && 
    u.Group.Rights.Any(f => f.Id == 2)
  select u;

 И получаем слегка укороченный SQL-запрос:

SELECT 
[GroupBy1].[A1] AS [C1]
FROM ( SELECT 
 COUNT(1) AS [A1]
 FROM [dbo].[Users] AS [Extent1]
 WHERE (N'pushkin' = [Extent1].[Login]) AND ( EXISTS (SELECT 
  1 AS [C1]
  FROM [dbo].[GroupRight] AS [Extent2]
  WHERE (2 = [Extent2].[Rights_Id]) AND ([Extent1].[Group_Id] = [Extent2].[Groups_Id])
 ))
)  AS [GroupBy1]

Colored with dumpz.org

 Я думаю, что на начальном этапе создания проекта, когда таблицы будут еще не слишком большими, подойдет и этот запрос, в дальнейшем же мы просто будем выносить все часто используемые не слишком оптимальные запросы в отдельные оптимизированные хранимые функции и процедуры. К счастью в Entity Framework 4 заложена возможность вызова хранимых процедур и функций, и не просто их вызова, а даже использования их в LINQ-запросах, что согласитесь очень хорошо.

Итак мы научились создавать модель данных, генерировать из нее схему данных, создавать сущности и делать из них выборку.

В следующей статье я планирую коснуться изменения (UPDATE) сущностей и изменения схемы данных (ALTER), создания и использования хранимых функций и процедур.

Проект можно скачать здесь test1