Вей-Менг Ли

На заре эпохи баз данных разработчикам достаточно было знать только те базы данных, которые они использовали. Но базы данных и их технологии развивались довольно быстро — от реляционных баз данных к нереляционным информационным хранилищам, таким, как электронная почта и файловые системы. Развитие баз данных сейчас идет в ногу со стремительными изменениями в технике. А с появлением клиент-серверных и многоуровневых архитектур разработчикам уже приходится разбираться во всем многообразии технологий баз данных. Большинство разработчиков потратили годы на изучение ODBC, DAO, RDO, OLE DB, ADO и RDS. К настоящему моменту Microsoft представила .NET Framework и вместе с ней новую технологию баз данных ADO.NET.

Как только мы начинаем углубляться в какую-то новую технологию, мы забываем, как она развивалась и что рационального за ней стоит. Проследив развитие технологий баз данных от ODBC до ADO.NET, проще выбрать подходящую технологию и оптимизировать ее для своих целей.

ODBC

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

Технология ODBC обеспечивает общий интерфейс для доступа к разнородным базам данных стандарта SQL. ODBC использует язык SQL как стандарт для доступа к данным. На Рисунке 1 показана архитектура ODBC. Этот интерфейс очень удобен: одно приложение может обращаться к различным базам данных SQL через общий набор команд. Таким образом, разработчик может создавать и распространять приложения, не привязываясь к конкретной базе данных.

Рисунок 1. Архитектура ODBC.

Можно также добавить драйвер базы данных, чтобы приложение могло работать с базой данных по выбору пользователя. Как показано на Рисунке 1, менеджер драйверов является промежуточным звеном между приложением и базами данных. Интерфейс ODBC содержит набор функций, который управляет каждым инструментом базы данных. Если приложению нужно сменить используемую базу, разработчик просто заменяет один драйвер другим, и приложение может работать как обычно, без необходимости модификации кода программы.

DAO и RDO

Рисунок 2. Использование DAO для доступа к базе данных.

ODBC использует низкоуровневый интерфейс, поэтому программисты на С и С++ реально задействуют все преимущества технологии ODBC. Программисты на Visual Basic (VB) не имеют простого доступа к интерфейсу ODBC. До появления VB 6.0 разработчики применяли высокоуровневый доступ к данным. На Рисунке 2 показано, как программисты VB используют технологию Data Access Object (DAO) для доступа к данным.

Рисунок 3. Использование RDO для доступа к базе данных.

DAO базируется на технологии баз данных Microsoft Jet — процессоре баз данных, предназначенном для Microsoft Access. JET был первым объектно-ориентированным интерфейсом для связи с Access. Приложения, использующие Access, могут задействовать DAO для прямого доступа к данным. Поскольку DAO создавалась сразу же вслед за Access, применение этой технологии — самый быстрый и наиболее эффективный способ доступа к базам данных Access. DAO может работать и с отличными от Access базами данных, такими, как SQL Server и Oracle. DAO использует ODBC, но, поскольку метод DAO спроектирован специально для взаимодействия с JET, JET транслирует запросы между DAO и ODBC. Этот дополнительный шаг трансляции и является причиной замедления работы с базами данных, отличными от Access.

Рисунок 4. Архитектура ODBCDirect.

Чтобы преодолеть это ограничение, разработчики Microsoft создали RDO. На Рисунке 3 показано, что RDO обращается к ODBС API напрямую, минуя JET. Затем было введено ODBCDirect, расширение DAO, которое отодвигает RDO на задний план. На Рисунке 4 показано, как DAO-приложение, используя ODBCDirect, обращается к базе данных, минуя проблемы, которые вызывает JET.

OLE DB

Спустя несколько лет ODBC становится стандартом для клиент-серверного доступа к базам данных. ODBC обеспечивает стандартный интерфейс, который требует функций SQL и оптимизирован под методы SQL. Однако что произойдет, если нужно будет обратиться к нереляционной базе данных, в которой не используются принципы SQL (например, Microsoft Exchange Server, хранилище которого не содержит данные реляционно).

Рассмотрим OLE DB. Технология OLE DB построена на ODBC и расширяет ее до компонентной архитектуры, которая обеспечивает высокоуровневый интерфейс доступа к данным. Эта архитектура предоставляет постоянный доступ к SQL-данным, не SQL-данным и неструктурированным источникам данных по локальным сетям и Internet. В действительности для доступа к SQL-данным OLE DB использует ODBC, потому что это самая подходящая архитектура для работы с SQL. На Рисунке 5 показано, что OLE DB состоит из трех компонентов: потребителя данных (например, приложения); поставщика (провайдера) данных, который содержит и предоставляет данные; служебного компонента, который обрабатывает и транспортирует данные (в частности, процессоры запросов, процессоры курсоров). OLE DB — это единый API, который обрабатывает как совместимые с SQL источники данных, так и несовместимые, такие, как почта и каталоги.

Рисунок 5. Компоненты OLE DB.

ADO

OLE DB обеспечивает связывание для программистов на С и C++, а также программистов, использующих языки с С-подобными вызовами функций. Такие языки, как VB и VBScript, не поддерживают тип данных «указатель» (адресных переменных). Следовательно, они не могут использовать связывание в стиле С и прямое обращение к OLE DB.

Вероятно, для большей путаницы разработчики Microsoft ввели еще одну объектную модель доступа к данным: ADO. ADO работает с объектами DAO и RDO, а также поддерживает более простые модели, чем DAO и RDO (хотя с избыточной функциональностью, так что можно выполнить операцию несколькими способами). Объектная иерархия в ADO более однородная, чем в DAO. ADO содержит несколько встроенных объектов, которые упрощают доступ к данным из информационных хранилищ.

На Рисунке 6 показано несколько способов, с помощью которых приложение связывается с базой данных. Например, VB-программист может использовать ADO для соединения приложения с провайдером OLE DB. Если база данных не поддерживает OLE DB, приложение может задействовать ODBC. Программист на Visual C++ может применять ADO или соединяться напрямую через OLE DB.

Рисунок 6. Различие маршрутов приложений в ADO.

Пример в ADO

Рассмотрим простой пример работы ADO. В Листинге 1 показано, как можно использовать типичный объект — набор строк (Recordset) — центральный объект в ADO. Объект Recordset представляет собой набор записей (таблицу) и поддерживает типы курсоров adOpenForwardOnly, adOpenKeyset, adOpenDynamic и adOpenStatic. Курсор может быть как на стороне сервера (по умолчанию), так и на стороне клиента.

Для доступа к записи ADO требуется просканировать набор строк последовательно. Для доступа к нескольким таблицам необходимо выполнить запрос на объединение JOIN, чтобы получить результат в виде набора строк. Хотя объект Recordset поддерживает доступ к данным без соединения с ними, ADO изначально был спроектирован для данных, с которыми установлено соединение. Такой метод доступа заставляет хранить важные ресурсы на стороне сервера. Вдобавок для передачи набора строк следует использовать метод упорядочивания, названный COM marshalling. COM marshalling — это процесс преобразования типов данных, который, естественно, занимает полезные ресурсы системы.

Начиная с ADO 2.1, Microsoft добавляет поддержку XML в объектную модель ADO, что позволяет хранить набор строк Recordset как XML-документ. Однако только при появлении ADO 2.5 ряд ограничений XML, который сохранялся в версии ADO 2.1 (например, жесткая иерархия объектов Recordset), был устранен. Хотя ADO может преобразовать документ XML в набор Recordset, он в состоянии читать только документы в собственной схеме, известной как Advanced Data TableGram (ADTG).

В поисках механизма доступа к несвязанным данным Microsoft расширяет ADO и вводит службу Remote Data Services (RDS). RDS создана после ADO и разрешает передачу объекта Recordset клиенту (например, в Web-браузер) при отсутствии активного соединения. Однако RDS, как и ADO, использует упорядочивание COM marshaling для передачи набора строк от сервера клиенту.

Эра .NET

Когда Microsoft начала разрабатывать .NET Framework, она имела хорошую возможность пересмотреть модель доступа к данным. Решив не продолжать разработку технологии ADO, специалисты Microsoft приступили к созданию новой структуры доступа к данным, при этом сохранив акроним. Microsoft разрабатывает ADO.NET на базе уже зарекомендовавшей себя объектной технологии ADO. Но ADO.NET ориентируется на три важные возможности, которые не поддерживаются ADO: поддержка модели доступа к несвязанным данным, что является ключевым элементом для работы в Web; поддержка тесной интеграции с XML; интеграция с .NET Framework (например, совместимость с базовой библиотекой классов типичной системы).

Архитектура ADO.NET. На Рисунке 7 представлена архитектура ADO.NET. Объект Recordset, который выполняет так много функций в ADO, здесь отсутствует. Вместо него в ADO.NET предусмотрено несколько особых объектов, выполняющих специфические задачи. В Таблице 1 описаны три из них: DataAdapter, DataReader и DataSet.

Рисунок 7. Архитектура ADO.NET.

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

Поставщик данных .NET состоит из четырех основных компонентов: Connection — для связи с источником данных; Command выполняет команды над источником данных; DataReader читает данные из источника данных в однонаправленном режиме «только чтение», и DataAdapter, который читает данные из источника данных и использует их для заполнения объекта DataSet.

Visual Studio .NET содержит два поставщика данных .NET. Поставщик данных SQL Server .NET обеспечивает связь с SQL Server 7.0 и более поздними версиями. Этот метод доступа наиболее эффективен для SQL Server 7.0 и выше, потому что поставщик данных SQL Server .NET связывается напрямую с SQL Server через протокол Tabular Data Stream (TDS). Поставщик данных OLE DB .NET необходим для соединения с отличными от SQL Server базами данных, такими, как Oracle или IBM DB2. Этот поставщик данных использует OLE DB для соответствующих баз данных.

Во время написания статьи разработчики Microsoft реализовали третий тип поставщика данных .NET — ODBC .NET Data Provider — Release Candidate Beta. Его можно получить на сайте Microsoft http://www.microsoft.com/data/ download_odbcnetrc.htm.

Рисунок 8. Различие маршрутов в ADO.NET.

На Рисунке 8 показаны различные пути, по которым приложение может связываться с базой данных через ADO.NET. При выборе пути сначала определяется, какой поставщик данных .NET будет использоваться. Если это SQL Server 7.0 или более поздняя версия, то подключается поставщик данных SQL Server.NET. Если база данных SQL Server 6.5 или отличная от SQL Server (например, Oracle), понадобится поставщик данных OLE DB .NET. Заметим, что можно задействовать поставщик данных OLE DB .NET для баз данных SQL 7.0 и выше, но тогда потеряется выигрыш в производительности, который дает прямое подключение к SQL Server через протокол TDS. Однако в этом неспецифическом способе есть свой плюс — мобильность, т. е. можно менять базы данных без модификации кода.

Далее необходимо определить, какую задачу требуется выполнить. Если надо просто прочитать и отобразить данные из источника данных, объекта Data Reader вполне достаточно. Но если предстоит манипулировать данными (например, редактировать или удалять), нужно использовать объект Data Set. Хотя задействовать этот объект следует только в случае необходимости, потому что он работает медленнее, чем Data Reader (Data Set использует Data Reader для заполнения таблиц).

Пример на ADO.NET

Рассмотрим, как ADO.NET действует в Web-службе. В Листинге 2 показана Web-служба, которая возвращает объект Data Set. Код в Листинге 2 похож на код в Листинге 1. Web-служба в Листинге 2 отыскивает таблицу Authors в базе Pubs и представляет ее как Web-службу. Web-служба использует поставщик данных SQL Server .NET, как показано в следующей строке:

Imports System.Data.SqlClient

Сначала Web-служба устанавливает связь с базой данных SQL Server 2000:

Dim conn AS New SqlConnection(«server=localhost;uid=sa; password=; database=pubs»)

Затем Web-служба, используя объект Command, выполняет запрос к базе данных:

Dim comm AS New SqlCommand(sql, conn)

Далее Web-служба с помощью объекта DataAdapter заполняет DataSet:

DataAdapter.Fill(ds, «Authors_table»)

Заметим, что соединение закрывается, как только Dataset заполнен, в отличие от соединений в ADO, которые должны быть открыты, пока существует соединение через RecordSet. Результирующий DataSet возвращается как Web-служба. На Экране 1 показан участок DataSet, который получается после вызова новой Web-службы. DataSet с его схемой представлен в формате XML. Клиентское приложение может выбрать привязку к этому DataSet, используя компонент DataGrid.

В Листинге 3 показан код, выполняющий данную привязку. На Экране 2 изображен результирующий DataSet, привязанный к элементу управления DataGrid в Web-приложении на ASP.NET, которое представит этот DataSet в более удобном виде. ASP.NET поддерживает много элементов управления, которые привязываются к DataSet автоматически.

Использование ADO в приложениях .NET

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

Но если процесс разработки продолжается, можно оставить ADO в старых проектах и использовать ADO.NET в новых. .NET Framework позволяет задействовать ADO в .NET приложениях через COM, который поддерживает обратную совместимость без необходимости модифицировать ADO. Нужно импортировать библиотеки типа ADO как сборку (см. Экран 3). Затем можно использовать ADO, как показано в коде в Листинге 4.

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