Entity Framework

Подключенный и автономный уровни ADO.NET снабжают фабрикой, которая позволяет выбирать, вставлять, обновлять и удалять данные с помощью объектов соединений, команд, чтения данных, адаптеров данных и DataSet. Хотя все это замечательно, эти аспекты ADO.NET заставляют трактовать полученные данные в манере, которая тесно связана с физической схемой данных.

Вспомните, например, что при использовании подключенного уровня обычно производится итерация по каждой записи за счет указания имен столбцов объекту чтения данных. С другой стороны, в случае работы с автономным уровнем придется иметь дело с коллекциями строк и столбцов объекта DataTable внутри контейнера DataSet.

При использовании подключенного и автономного уровней ADO.NET всегда приходится помнить о физической структуре лежащей в основе базы данных. Необходимо знать схему каждой таблицы данных, писать сложные SQL-запросы для взаимодействия с данными таблиц и т.д. Это вынуждает писать довольно громоздкий код C#, поскольку C# существенно отличается от языка самой базы данных.

Вдобавок способ конструирования физической базы данных (администратором баз данных) полностью сосредоточен на таких конструкциях базы, как внешние ключи, представления и хранимые процедуры. Сложность баз данных, спроектированных администратором, может еще более возрастать, если администратор при этом заботится о безопасности и масштабируемости. Это также усложняет код C#, который приходится писать для взаимодействия с хранилищем данных.

Платформа ADO.NET Entity Framework (EF) — это программная модель, которая пытается заполнить пробел между конструкциями базы данных и объектно-ориентированными конструкциями. Используя EF, можно взаимодействовать с реляционными базами данных, не имея дело с кодом SQL (при желании). Исполняющая среда EF генерирует подходящие операторы SQL, когда вы применяете запросы LINQ к строго типизированным классам.

LINQ to Entities — это термин, описывающий применение запросов LINQ к сущностным объектам ADO.NET.

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

В Microsoft считают ADO.NET Entity Framework новым членом семейства технологий доступа к данным, и не намерены заменять им подключенный и автономный уровни. Однако после недолгого использования EF часто отдается предпочтение этой развитой объектной модели перед относительно примитивным миром SQL-запросов и коллекций строк/столбцов.

Тем не менее, иногда в проектах.NET используются все три подхода, поскольку одна только модель EF чрезмерно усложняет код. Например, при построении внутреннего приложения, которому нужно взаимодействовать с единственной таблицей базы данных, подключенный уровень может применяться для запуска пакета хранимых процедур. Существенно выиграть от использования EF могут более крупные приложения, особенно если команда разработчиков уверенно работает с LINQ. Как с любой новой технологией, следует знать, как (и когда) имеет смысл применять ADO.NET EF.

Давайте рассмотрим архитектуру EF:

Составные части архитектуры ADO.NET Entity Framework не столь сложны, как могут показаться на первый взгляд. Давайте рассмотрим их более подробно.

Строго типизированные классы, упомянутые ранее, называются сущностями (entities). Сущности — это концептуальная модель физической базы данных, которая отображается на предметную область. Формально говоря, эта модель называется моделью сущностных данных (Entity Data Model — EDM). Модель EDM представляет собой набор классов клиентской стороны, которые отображаются на физическую базу данных.

Тем не менее, нужно понимать, что сущности вовсе не обязаны напрямую отображаться на схему базы данных, как может показаться, исходя из названия. Сущностные классы можно реструктурировать для соответствия существующим потребностям, и исполняющая среда EF отобразит эти уникальные имена на корректную схему базы данных.

Например, вспомним простую таблицу Inventory, схема которой показана на рисунке:

Если сгенерировать EDM для таблицы Inventory, то по умолчанию сущность будет называться Inventory. Тем не менее, сущностный класс можно переименовать в Car и определить для него уникально именованные свойства по своему выбору, которые будут отображены на столбцы таблицы Inventory. Такая слабая привязка означает возможность формирования сущностей так, чтобы они наиболее точно соответствовали предметной области.

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

API-интерфейс EF находится на вершине существующей инфраструктуры ADO.NET. Подобно любому взаимодействию ADO.NET, сущностная платформа использует поставщик данных ADO.NET для взаимодействия с хранилищем данных. Однако поставщик данных должен быть обновлен, чтобы поддерживать новый набор служб, прежде чем он сможет взаимодействовать с API-интерфейсом ЕF. И как можно было ожидать, поставщик данных Microsoft SQL Server уже обновлен соответствующей инфраструктурой, которая полагается на использование сборки System.Data.Entity.dll.

Многие сторонние базы данных (например, Oracle и MySQL) предлагают EF-совместимые поставщики данных. Детальную информацию можно узнать у поставщика системы управления базами данных или просмотреть список известных поставщиков данных ADO.NET.

В дополнение к добавлению необходимых компонентов к поставщику данных Microsoft SQL Server, сборка System.Data.Entity.dll содержит различные пространства имен, которые сами полагаются на службы EF. Две ключевых части API-интерфейса EF, на которые следует обратить внимание сейчас — это службы объектов (object services) и клиент сущности (entity client).

Дата добавления: 2015-05-09