Entity Framework rationale

Традиционные клиент-сервер приложения делегируют операции запроса и сохранения информации системам баз данных. Последние оперируют данными в форме строк и таблиц, а приложения - в рамках высокоуровневых конструкций языка (классы, структуры). Такая нестыковка имеет вполне определенное имя - Object-relational impedance mismatch. С наступлением эпохи SOA, серверов приложений а также многоуровневых приложений, необходимость в службах манипуляций данными, которые тесно интегрированы со средой разработки, крайне возросла.

ADO.NET Entity Framework - это платформа разработки data-driven приложений, которая повышает уровень абстракции с реляционного уровня до концептуального, тем самым существенно уменьшая проблему impedance mismatch.

Мотивация

Текущие практики моделирования приложений разделяют модель данных на четыре основных уровня:

1. Физическая модель.

   Описывает способ хранения данных в контексте физических ресурсов - память, диски, форматы, индексы и т.д.

2. Логическая (реляционная) модель.

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

3. Концептуальная модель.

   Охватывает основные информационные сущности предметной области, а также их связи. Хорошо известная всем (и самая популярная) Entity-Relationship Model была представлена Peter Chen в 1976 году. UML является более свежим примером концептуальной модели. Большинство приложений входят в этап концептуального прототипирования на ранних этапах жизненного цикла приложений. К сожалению, концептуальные модели остаются картинками, которые невозможно совместить с реалиями реализации. Важным достижением Entity Framework является возможность представления концептуальнй модели, как реальной абстракции платформы разработки.

4. Модель программирования\представления.

   Описывает представление артефактов концептуальной модели. Что-то необходимо преобразовать в объекты языка программирования для реализации бизнес логики, другое нужно передать в виде потока XML и т.д. Короче, необходим гибкий механизм трансформации.

Большинство приложений и служб обработки информации разрабатываются в рамках высокоуровневых концепций (Клиент, Заказ, Товар), а не применительно к таблицам БД или битам-байтам. Товар может быть представнен бесконечным количеством форм и здесь нет единственно правильной концепции. Конечный вид зависит от решаемой задачи, но настоящая ценность - это конкретная концептуальная модель, которая является базисом для гибких преобразований и использования на более высоком уровне абстракции.

Entity Framework - это платформа разработки, которая повышает уровень абстракции с реляционного до концептуального. Она имеет собственный язык запросов, гибкую архитектуру. До некоторой степени концептуальная модель не зависит от реляционной - отображение является независимой внешней единицей метаданных. Получается, можно менять схему базы данных в некоторых границах без аффекта кода приложения. Механизм провайдеров теоретически позволяет использовать любую базу данных, которая удовлетворяет требованиям Entity Framework.

В моей вступительной статье The splendour and misery of Entity Framework designer, architecture and runtime я рассказывал о Entity Data Model, или сокращенно - EDM. Зачем понадобилось изобретать колесо в виде новой концепции моделирования? Было ли действительно изобретено колесо? Почему бы не использовать или расширить одну из существующих концепций моделирования? Кандидаты на эту позицию следующие:

1. SQL data model.

   Стандарт SQL99 расширяет модель, добавляя объектно-реляционные возможности.

2. Managed data model (CLR).
3. XSD data model.
4. UML data model.

Конечная причина - необходимость безболезненного отображения одновременно на язык программирования для кодирования и реляционную базу данных для сохранения. Ни один из кандидатов не обладал требуемыми характеристиками.

Важным аспектом Entity Data Model является ориентированность на данные (как в SQL), а не на объектно-ссылочные концепции (как в C#). Именно поэтому Entity Framework больше тяготеет к ORM нежели к доменной модели приложения. Именно поэтому Entity Framework имеет мощный язык запросов - eSQL. При этом ничто не мешает построить уровень бизнес логики поверх концептуальной модели Entity Framework.