Дизайн модели данных и ее использование в клиент-серверном приложении

⇐ ПредыдущаяСтр 6 из 9Следующая ⇒

Открываем Visual Studio 2010 и создаем обычное консольное приложение. Присваиваем ему имя test1. Добавляем в проект модель данных. В Solution Explorer из контекстного меню 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…):

Entity Name = User

Entity Set = Users

Остальные свойства оставим без изменений. Заметим лишь, что по умолчанию дизайнер модели создает первичный ключ Id целочисленного типа, что для нас вполне приемлемо.

Добавляем в эту сущность свойства(Properties):

Registered (Type = DateTime)

Свойства добавляются в контекстном меню самой сущности (Add -> Scalar Property).

Entity Name = Group

Entity Set = Groups

Свойства:

Name (Type = String, Max Length = 255)

Entity Name = Right Entity Set = Rights

Свойства:

Description (Type = String, Max Length = 255)

Итак, теперь у нас есть три сущности, пока еще не связанные друг с другом. Займемся этим вопросом.

Создаем связи (Add -> Association):

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

Это соотношение “Многие ко многим”, то есть группа содержит в себе множество прав, при этом каждое право может принадлежать нескольким различным группам.

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

Рис. 5.3 Схема данных

Обратите внимание, что после создания связей, в каждой из сущностей появились дополнительные навигационные свойства. Например, свойство 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

Рис. 5.4 Схема базы данных в сервере баз данных

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

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

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

MyEFModelContainer cnt =

new MyEFModelContainer("name=MyEFModelContainer");

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

metadata=res://*/MyEFModel.csdl|res://*/MyEFModel.ssdl|res://*/MyEFModel.msl;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()

{

Registered = DateTime.Now,

Group = groupReaders

};

User userPushkin = new User()

{

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();

}

// Создаем объекты прав

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()

{

Registered = DateTime.Now,

Group = groupReaders

};

User userPushkin = new User()

{

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();

}

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

Рис. 5.5 Структура таблиц с данными

Рассмотрим теперь алгоритм выборки данных из контейнера. Для этих целей буду использовать язык встроенных запросов 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());

}

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]

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]

Здесь видим безобразный 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;

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]

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]

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

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

⇐ Предыдущая 1 2 3 4 567 8 9 Следующая ⇒

Последнее изменение этой страницы: 2019-04-19; Просмотров: 304; Нарушение авторского права страницы