На заре эпохи баз данных разработчикам достаточно было знать только те базы данных, которые они использовали. Но базы данных и их технологии развивались довольно быстро — от реляционных баз данных к нереляционным информационным хранилищам, таким, как электронная почта и файловые системы. Развитие баз данных сейчас идет в ногу со стремительными изменениями в технике. А с появлением клиент-серверных и многоуровневых архитектур разработчикам уже приходится разбираться во всем многообразии технологий баз данных. Большинство разработчиков потратили годы на изучение 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 для доступа к базе данных. |
|
| Рисунок 3. Использование RDO для доступа к базе данных. |
|
| Рисунок 4. Архитектура ODBCDirect. |
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. |
Далее необходимо определить, какую задачу требуется выполнить. Если надо просто прочитать и отобразить данные из источника данных, объекта 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.
В заключение хочу добавить, что технологии доступа к базам данных постоянно развиваются. Пока осваивается одна технология, уже появляется другая. Только одно остается неизменным: базы данных играют все более важную роль при разработке приложений. Знание новейших технологий и эволюционных изменений, которые они вызывают, поможет найти оптимальную технологию для текущей задачи и сделать обоснованный выбор в случае необходимых изменений.
НР представляет первую 64-разрядную рабочую станцию ХР
HP объявила о полномасштабной готовности первых рабочих станций на базе процессора Itanium 2, работающих под управлением Windows XP 64-Bit Edition Version 2003. Предлагаются две конструктивные реализации концепции, а именно: HP Workstation zx2000 и Workstation zx6000 с поддержкой одного и двух процессоров и оперативной памятью 8 Гбайт и 24 Гбайт, соответственно. Как отмечают представители Microsoft, XP 64-Bit Edition Version 2003 является высокопроизводительной платформой, способной поддерживать мощные Windows-приложения нового поколения на рабочих станциях на базе Itanium 2. Платформа предназначена для обслуживания наиболее сложных технических, научных и связанных с обработкой цифровой информации приложений. Стартовая ценовая планка для рабочих станций HP установлена на уровне 3300 долларов.
Вей-Менг Ли — преподаватель института School of Information and Communications Technology, Сингапур. Автор книги «XML Programming using the Microsoft XML parser» (Apress). С ним можно связаться по адресу: wei_meng_lee@hotmail.com.
Таблица 1. Некоторые особые объекты ADO.NET.
| Объект | Описание |
| DataAdapter | Объект, соединяющий базу данных с объектом DataSet. Основное преимущество DataAdapter состоит в том, что он может работать с любыми источниками данных. Источник данных может быть как базой данных, так и XML-документом. |
| DataReader | Объект обеспечивает эффективный поиск данных на стороне сервера. DataReader соединяется в однопроходном режиме "только чтение". Этот объект полезен для Web-приложений, которые используют DataReader для отображения данных на Web-страницах. |
| DataSet | Объект поддерживает копии записей из базы данных без соединения. Он сохраняет записи из таблицы (или множества таблиц) в памяти, не поддерживая постоянного соединения с сервером. В памяти DataSet представляет собой двоичный объект. Когда его перемещают или преобразуют, он представляется как DiffGram - формат XML. Поскольку XML - это текстовый формат, записи могут передаваться по Web - в обход ограничений брандмауэров. DataSet также содержит различные объекты, такие, как ограничения, зависимости и представления, которые позволяют работать с таблицами на клиентской стороне, а не только с RecordSet, как в ADO. |