Ни одна другая компания не предложила программистам и пользователям такого количества технологий для доступа к данным, как это сделала корпорация "Майкрософт". DAO, ADO, OLEDB, ODBC... Все перечислять долго (хотя ниже они все будут перечислены и даже снабжены краткими описаниями). Такое обилие не может не запутать. И поэтому, хотя большинству из этих технологий, по компьютерным меркам, уже много лет, до сих пор те, кто сталкивается с ними впервые, страдают от необходимости выбора. Надеюсь, эта статья послужит началом процесса понимания сути эти технологий и сможет служить для начального знакомства с большинством из них.

Все эти технологии используются для унификации доступа к различным СУБД из прикладных приложений. Такая задача стояла довольно остро в те годы, когда все эти технологии разрабатывались, и, в принципе, актуальности не потеряла до сих пор. Именно поэтому стоит об этих технологиях немного поговорить.

ODBC

Одна из первых технологий, которую Microsoft предложила для унификации доступа к источникам данных, имеет название Open Database Connectivity (по-русски это что-то вроде "открытого интерфейса взаимодействия с базами данных"). Что интересно, эта технология стала одной из самых популярных среди всех придуманных Редмондским гигантом, - наверное, из-за того, что, по своей сути, она гораздо проще большинства придуманных позже аналогичных технологий.

Что такое ODBC? Это программные интерфейсы (API) на языке C для подключения приложений к различным СУБД. При подключении при помощи ODBC приложение становится независимым от используемого источника данных (и от используемой СУБД). Независимость реализуется с помощью промежуточных библиотек, которые включают в себя код, специфичный для данной СУБД, и которые предоставляют унифицированный интерфейс для ODBC-приложений. Такие библиотеки называются ODBC-драйверами, и их обычно предоставляют сами разработчики СУБД. Или какие-нибудь сторонние производители - в принципе, для прикладного программиста не так уж существенно, кто предоставляет ему драйверы.

Единственное неудобство ODBC - это отсутствие объектно-ориентированного подхода. Правда, в библиотеке MFC, которую Microsoft рекомендует для разработки прикладных приложений с помощью Visual C++, есть классы для работы с данными через ODBC. Однако полностью объектную модель реализовала только следующая в нашем списке технология от Microsoft.

OLE DB

ODBC была удобной и популярной технологией, но для дальнейшего развития её идей Microsoft предложила пользователям OLE DB. Эта технология - в некотором роде гибрид ODBC и COM, то есть для доступа к данным в ней используются не API на языке C, а COM-интерфейсы. То есть эта технология предоставляет объектно-ориентированный интерфейс для любых языков программирования, совместимых с COM, а не только для Visual C++.

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

OLE DB может работать и через ODBC-соединения при помощи специального драйвера, который подключается к ODBC-драйверам. Эта связка, конечно, создаёт дополнительное звено в цепочке подключений, но в случае отсутствия нужных OLE DB-драйверов и наличия оных для ODBC вполне можно этим механизмом соединения воспользоваться.

RDO

При том, что OLE DB инкапсулирует и развивает идеи ODBC, дальше идей это не идёт. То есть, эти две библиотеки являются независимыми друг от друга, и именно поэтому для того, чтобы "стыковать" их, нужны специальные драйверы. Однако есть технология, которая базируется на ODBC, но предоставляет объектно-ориентированный интерфейс доступа к данным. Называется эта технология RDO (Remote Data Objects - удалённые объекты данных).

Правда, стоит сказать, что технология эта уже не самая молодая. Первая версия её была представлена ещё в 1995 году, и приурочено это событие было к выходу Visual Basic 4.0. Более поздняя версия этой технологии (но уже под названием ODBC Direct) была внедрена в Microsoft Office 97. Первоначально RDO продвигалась в качестве альтернативы другой технологии, DAO (о ней чуть ниже), но в итоге эти технологии как бы умерли вместе. В принципе, сейчас RDO существует только для обратной совместимости с не слишком значительным количеством приложений, так что особо углубляться в неё нет смысла.

DAO

DAO - это Data Access Objects (объекты доступа к данным). Ничего общего с китайской философией и Дао она не имеет. Первоначально эта технология была создана как COM-интерфейс для работы с СУБД Jet, которая позволяла работать с базами данных Microsoft Access и любыми, для которых имелись драйверы ODBC. Правда, после этого команда разработчиков DAO расширила возможности своего детища, создав ещё одну универсальную технологию для работы с данными. Правда, технология не пользовалась особой популярностью, за исключением тех случаев, когда требовалась именно работа с Jet. Сейчас она тоже особой популярностью не пользуется, поскольку уже значительно устарела (дальнейшая разработка прекращена в 2001 году).

ADO

Если переставить буквы в аббревиатуре DAO, получим слово ADO. Это ещё одна технология доступа к данным от Microsoft. Расшифровывается она как ActiveX Data Object (ActiveX-объекты для доступа к данным). Следует отметить, что это одна из самых популярных (после ODBC) технологий, разработанных в этой области корпорацией Microsoft.

На самом деле ADO - это просто ещё одна надстройка над уже существующими технологиями всё той же корпорации. В ней используются ActiveX-компоненты, являющиеся надстройками над API OLE DB, которое само по себе, в общем-то, не так уж и удобно в применении. ADO, конечно, вносит дополнительный уровень, который сказывается на производительности приложений, однако это так хорошо отражается на времени разработки, что технология намного популярнее, чем, собственно, OLE DB. Ещё один её плюс - возможность использования объектов для доступа к данным из скриптовых языков, таких, как VBScript или Jscript. Здесь немалую роль играет возможность её использования при программировании на ASP для разработки web-приложений.

ADO.NET

Новое поколение объектов для работы с данными, где вместо ActiveX-компонентов используются компоненты .NET. Сложно сказать, насколько ADO.NET является продолжением ADO... Наверное, её лучше рассматривать как совершенно самостоятельную технологию, поскольку это одна из центральных частей .NET Framework. Из-за особенностей .NET Framework эта технология довольно существенно отличается от "обычной" ADO.

MDAC

Microsoft Data Access Components (компоненты доступа к данным корпорации Microsoft) - это общее название ODBC, OLE DB и ADO. Или, если быть точным, это совокупность библиотек, обеспечивающих работу перечисленных технологий. Как правило, эти библиотеки присутствуют в операционной системе, однако, если по каким-то причинам комплект MDAC не установлен, его можно скачать для установки по адресу msdn2.microsoft.com/en-us/data/aa937730.aspx.

MSDE

Раз уж упоминалась СУБД Jet, то стоит сказать и о Microsoft Data Engine (движок для работы с данными от Microsoft). Это не универсальная технология доступа к данным наподобие ADO или OLE DB, просто однопользовательская настольная СУБД, совместимая с форматом баз данных Microsoft SQL Server'а. Фактически, это "обрезанный" для нужд настольных приложений SQL Server. MSDE позиционируется Microsoft как современная альтернатива СУБД Jet, более мощная и надёжная.

Итак, вот они, технологии. Их много, а ведь есть и другие, не только те, которые придуманы Microsoft. Например, для работы с данными в приложениях, написанных на Java, используется JDBC - Java Database Connectivity. Есть технология dbExpress фирмы Borland, которая тоже предоставляет универсальный и удобный доступ к различным СУБД при помощи специальных драйверов. Да и даже если выбирать из технологий, которые предлагает исключительно и только Microsoft, то на какой из них остановить свой выбор? Давайте попробуем разобраться вместе.

ODBC - самая универсальная и надёжная из всех технологий, к тому же в некотором роде кросс-платформенная, поскольку существует UnixODBC. Кроме того, за счёт того, что ODBC - технология с солидным стажем присутствия на рынке, то и драйверов для различных СУБД под неё написано очень много. Правда, отсутствие объектного API несколько отрицательно сказывается на скорости разработки приложений, но, тем не менее, существуют библиотеки, являющиеся оболочками для её функций и позволяющие работать с данными как с объектами (если позволяет язык программирования, конечно). OLE DB тоже появилась не вчера, и драйверов для неё тоже достаточно много. Но напрямую её используют редко, поскольку намного удобнее работать с OLE DB через объекты ADO. При этом, что самое интересное, нередко в прикладных приложениях наблюдается связка ADO-OLE DB-ODDC-СУБД. Если скорость и стабильность работы для приложения не очень критичны, то такая связка вполне приемлемое решение.

Вполне ясно, что использовать устаревшие технологии (RDO или DAO) не имеет смысла. Лучше пользоваться тем, что Microsoft продвигает в настоящий момент активнее всего - то есть, ADO.NET. Правда, использование этой технологии ограничивает вас платформой Microsoft .NET, но ведь ни одна технология Microsoft (кроме ODBC) не даёт достаточно свободы, ограничивая приложения, разрабатываемые с их помощью, работой под ОС Windows. Поэтому наиболее оптимальным решением я бы назвал ADO и ADO.NET. А если важна скорость работы, можно воспользоваться ODBC, правда, в таком случае будет ещё лучше подсоединяться к серверу БД напрямую.

Кстати, говоря об обилии технологий доступа к данным от Microsoft, стоит упомянуть интересную точку зрения на это самое обилие. Джоэл Спольски, о книге которого я рассказывал на страницах "КВ", считает, что это замечательная стратегия корпорации Microsoft: пока все мечутся и переходят с одной технологии доступа к данным на другую, корпорация спокойно идёт вперед, поскольку таким образом ресурсы, которые разработчики могли бы потратить на совершенствование приложений, уходят на переливание из пустого в порожнее. Поэтому, пользуясь этими технологиями, важно помнить об опасности угодить в такую ловушку. Выбирать технологию нужно с учётом возможных перспектив дальнейшей разработки продукта, которые могут быть весьма широкими. Потому что строить дом, как известно, дешевле, чем его перестраивать.

Вадим СТАНКЕВИЧ