Большую часть данной главы мы посвятили "стандартному" процессу создания .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, который помогает решать эту задачу.