Большую часть данной главы мы посвятили "стандартному" процессу создания .NET- приложений, которые читают и пишут данные, находящиеся в базе данных. Несмотря на то, что Visual Studio и сами библиотеки ADO.NET делают многое для того, чтобы абстрагиро­вать сложные элементы этого процесса, некоторые проблемы все же остаются.

Фактически существует одна общая проблема, с которой сталкиваются разработчики приложений для работы с данными: различие между объектно-ориентированной моделью программирования приложения (реализованной на языках C# или Visual Basic) и реляционной моделью про­граммирования (реализованной в основном на SQL в базах данных или наборах данных).

В мире объектно-ориентированного программирования мы манипулируем объектами по­средством их методов и свойств, и каждый такой объект может быть (и часто является) ро­дителем или контейнером для других объектов. Мир реляционных баз данных гораздо про­ще: объекты реализованы как таблицы из строк/столбцов и каждая "ячейка" таблицы содержит простое скалярное значение. Основная проблема состоит в том, что вы должны менять модель программирования при переходе от работы с внутренней инфраструктурой приложения к работе с реляционной базой данных (используемой в качестве хранилища данных приложения). А такой переход является непростой задачей.

Простой пример: строки из таблицы счетов легко выбрать в объект набора данных (исполь­зуя уже обсуждавшиеся ранее различные инструменты привязки данных и классы). Но для получения из набора данных "родного" объекта Invoice потребуется выполнить вручную двустороннюю трансляцию и обработку (для того чтобы транслировать основные значения через эту границу объект/реляционность). Так появляется несколько проблем: откажетесь ли вы от подхода на основе наборов данных и будете читать напрямую из базы данных в объ­екты вашего приложения? Воздержитесь ли вы от объектного подхода и попытаетесь ис­пользовать компонент DataSet во всех уровнях вашего приложения? Или лучше использо­вать комбинированный подход — поддерживая строго типизированные коллекции объектов в дополнение к наборам данных?

В идеале разработчики приложений должны были бы иметь возможность работать с объек­тами в объектной модели программы и автоматически сохранять эти объекты и их измене­ния в базе данных (при минимальном своем участии). При этом внимание сосредоточено на основных и хорошо изученных шаблонах конструирования объектов, и, кроме того, разра­ботчик может работать на своем основном языке программирования (без необходимости изучать SQL). Реализация этой цели совершенно очевидным образом потребует стандарти­зированного подхода и поддержки инструментальными средствами (для установления соот­ветствия между объектами и их эквивалентами в реляционной базе данных). Именно это делают инструменты отображения объектности/реляционности.

Термин "объектно-реляционная проекция" (O/R mapping) используется для обозначения этого общего процесса трансляции объектов в базы данных и обратно. Инструменты объ- ектно-реляционной проекции присутствуют на рынке уже много лет и (к счастью) фирма Microsoft, наконец, встроила поддержку этой проекции непосредственно в .NET Framework и Visual Studio. Эта технология называется LINQ для SQL. Давайте же кратко обсудим кон­цепцию L1NQ для SQL, а затем рассмотрим инструмент Visual Studio — конструктор O/R Designer, который помогает решать эту задачу.