Document 4122240

http://mega.km.ru/pc/srch.asp
Visual Basic 5.0 и способы доступа к данным
Существует
множество
возможных решений
проблемы
взаимодействия с данными. Цель данной статьи — помочь
разработчикам программных продуктов понять, какой из способов
взаимодействия приложений с базами данных является актуальным и
наиболее перспективным для разрабатываемых сегодня систем.
Зачастую разработчики считают, что весьма затруднительно
создавать коммерческие приложения, ориентируясь на перспективные
технологии, которые в текущий момент еще не удовлетворяют
насущным требованиям. Это действительно так, поэтому в данной
статье
даны
некоторые
рекомендации,
которые
помогут
разработчикам оценить ситуацию с использованием тех или иных
способов доступа к данным.
Я рекомендую Visual Basic в качестве основного инструмента в
силу его наилучшей взаимосвязи с наиболее перспективными
технологиями. В настоящий момент для работы с данными,
хранящимися в реляционных серверных базах, применяется механизм
Remote Data Access Objects (RDO) версии 2.0, в то время для
настольных реляционных баз широко применяется механизм Data
Access Objects (DAO/Jet). Оба интерфейса глубоко интегрированы в
Visual Basic и являются его ключевой частью.
Производительность RDO 2.0 существенно возросла по
сравнению с его первой версией, однако имейте в виду, что RDO
входит только в Enterprise-редакции любого из средств разработки,
входящих в состав Visual Studio.
Active Data Objects (ADO), разрабатываемые в течение
последних полутора лет, соединили в себе наилучшие свойства DAO
и RDO и призваны со временем их заменить. Если сегодня вы
используете RDO, то не составит большого труда перепроектировать
ваше приложение под ADO, так как их архитектура довольно похожа.
Существующий в настоящий момент интерфейс ADO 1.5 не включен в
состав Visual Basic 5.0, хотя на Visual Basic легко можно писать
программы, использующие ADO. В последующих выпусках Visual Basic
данный интерфейс станет его составной частью.
Каждого разработчика волнует вопрос: следует ли применять
ADO уже сегодня? Обеспечит ли это те возможности, которыми
обладают сейчас RDO 2.0 или DAO 3.5. Ответ — да. Microsoft
рекомендует разработчикам мигрировать на ADO, поскольку это
стратегический интерфейс. В течение ближайших полутора лет ADO
призван стать единым интерфейсом общения с источниками данных
вне зависимости от их природы. Тем не менее, Microsoft гарантирует,
что существующие интерфейсы взаимодействия с данными будут
поддерживаться (по крайней мере, в ближайших версиях).
На протяжении последних нескольких лет программисты,
использующие Visual Basic, создали множество разнообразных
программ, компонент и сложных коммерческих решений. Свыше 80%
этих разработок работают с различными данными — от текстовых
файлов до серверных баз данных и распределенных данных на
мэйнфреймах. Был создан ряд программ, использующих механизм
VBSQL. Для того, чтобы удовлетворить запросы разработчиков,
использующих Visual Basic и Access, корпорация Microsoft
разработала два механизма — Microsoft Jet Database Engine (кратко —
Jet) и Data Access Objects (DAO), чтобы дать возможность легко
взаимодействовать с этими базами данных.
Visual Basic 5.0, кроме того, включает в свой состав абсолютно
новый редактор запросов (Query Connection designer) для
автоматизации создания сложных вызовов во время разработки
приложения. Он позволяет в несколько раз уменьшить время,
приходящееся на простое написание вызывающего кода, и в то же
время использует все возможности интерфейсов, предоставляемые в
распоряжения разработчика.
В общей сложности разработчики, которые используют Visual
Basic 5.0 в качестве инструмента, могут при разработке приложений
использовать один из девяти способов взаимодействия с данными при
создании клиентских или серверных компонент приложений. Каждый
из них способен удовлетворить конкретные потребности клиента.
Интерфейсы Visual Basic 5.0
Приведенная таблица суммирует все интерфейсы, доступные в
настоящий момент из Visual Basic 5.0. Некоторые из них представляют
не что иное, как интерфейсы прикладного программирования
(applications programming interfaces — API), но большинство из них
является COM-интерфейсами.
В следующей таблице перечислены способы доступа к данным,
доступные программным способом, хотя некоторые программисты
используют связанные с данными элементы управления (data bound
controls) для того, чтобы избавиться от рутинной работы по написанию
кода, реализующего пользовательский интерфейс и отображение в
нем данных, извлеченных из баз. Visual Basic, кроме того,
поддерживает несколько элементов управления, являющихся
дополнительным интерфейсом между Visual Basic и COMинтерфейсами доступа к данным (data source controls). Эти элементы
в основном обеспечивают механизм, позволяющий обойтись
минимумом непосредственного кодирования в ущерб, естественно,
эффективности.
В течение последних нескольких лет ODBC являлся основным
механизмом для работы с удаленными данными, в то время как
интерфейсы Jet или ISAM применялись для работы настольными
базами. Все они в некоторой степени перекрывали функциональные
возможности друг друга с целью удовлетворения любых
специфических потребностей пользователей.
Каждый ли знает, что означают все эти разнообразные
аббревиатуры? Следующая таблица коротко объясняет значение
каждой из них.
Использование интерфейсов прикладного программирования
(API)
Считается, что интерфейсы прикладного программирования
низкого
уровня
гарантированно
обеспечивают
высокую
производительность
приложений,
чего
всегда
добиваются
программисты, но и требуют значительных временных затрат, чего не
могут допустить руководители проектов. Однако это не всегда верно.
В практике создания сложных программных систем нередки случаи,
когда ни ODBC, ни VBSQL не обеспечивают более высокой
производительности, чем версия RDO 2.
Использование элементов управления данными (Data Source
Controls)
В большинстве случаев элементы управления данными, такие,
как DAO/Jet Data Control или элемент управления удаленными
данными RDO (Remote Data control) позволяют разработчикам быстро
отображать выборки данных без написания дополнительного кода.
Однако они не заменяют обычного проектирования приложения, т. к.
при их использовании может открываться неоправданно много связей
(connect) с источником данных или излишне ресурсоемкие курсоры, и
т. п. Тем не менее, при работе с графическими образами,
хранящимися в базе, такие элементы представляют собой заметное
подспорье в работе. Да и при работе со скроллируемыми выборками
данных их применение может заметно сократить код и упростить
разработку.
Использование COM-интерфейсов
COM-интерфейсы в настоящий момент являются широко
распространенным
способом
взаимодействия
приложения
и
специализированных библиотек. Именно полная интегрированность
VB и COM-модели построения программы позволяет весьма легко
писать приложения, использующие COM-интерфейсы.
ODBC
ODBC представляет собой API-интерфейс к менеджеру ODBC
драйверов и, соответственно, к набору управляемых им ODBC
драйверов. ODBC API совершенно не приспособлен для работы с
ISAM базами данных, потому что он не имеет функций для поиска и
установки диапазонов, выбора индексов и управления ими, т. е. не
имеет всего того, с чем привыкли работать разработчики,
применяющие базы данных ISAM типа. И это естественно, так как он
создавался для других целей. Безусловно, можно использовать
ODBC-драйвер Jet, но это означает, что он просто загрузит механизм
для конвертирования ISAM-данных в реляционные и будет
использовать только набольшую часть своего реального потенциала
для работы как с ISAM, так и оригинальными Jet-базами данных.
Механизм
ODBC
обеспечивает
интерфейс,
способный
удовлетворить специфические потребности при взаимодействии
приложения и базы данных. Он обеспечивает прямые вызовы API,
которые могут служить для наилучшего использования возможностей,
предоставляемых в распоряжение разработчика конкретными базами
данных. Подобный интерфейс, безусловно, значительно труднее
программировать, чем объектный, но он обеспечивает лучшую
степень контроля над источником данных. Его использование из Visual
Basic трудно назвать легким и дружественным, так как он требует
включения в текст программы значительных фрагментов исходного
кода.
VBSQL
VBSQL в течение ряда лет являлся основным интерфейсом для
ряда разработчиков, программирующих на Visual Basic, и продолжает
играть эту роль для тех устаревших 16-разрядных приложений,
которые не были переведены на 32-разрядные платформы.
DAO/Jet
DAO представляет собой ни что иное как COM-интерфейс к
механизму взаимодействия с базами данных класса Jet, а версия DAO
3.5 — интерфейс к механизму обработки серверных баз данных RDO
2.0. При этом, однако, не следует забывать, что первоначально
DAO/Jet проектировался для работы с базами данных ISAM типа и,
следовательно, представляет собой хороший вариант решения только
в том случае, если работает с базами данных формата Jet (MDB) или
ISAM (Btrieve, FoxPro, Paradox и dBase).
Использование DAO-интерфейса при написании приложений
намного легче, чем использование Jet API, однако при работе с
серверными базами данных он может оказаться менее эффективным,
чем непосредственно API интерфейс или RDO. Кроме того, хотя
DAO/Jet умеет работать с источниками данных через ODBC, он имеет
ограниченные возможности по работе с хранимыми процедурами и
обработке множественных результатов запросов. Он также не
позволяет строить курсоры на сервере и много другое.
ODBCDirect
Первоначально DAO обращался непосредственно к Jet, однако с
появлением DAO версии 3.5 объектный интерфейс DAO был отделен
от Jet и разработчики, наконец, получили долгожданную альтернативу
— возможность работать с ODBC напрямую, минуя Jet. Это имеет
принципиальное значение для тех разработчиков, которые создают
решения на базе Microsoft Office и нуждаются в той высокой
производительности, функциональности и гибкости, которая имеется у
RDO, но которую они не могут использовать по лицензионным
соображениям (RDO входит в состав только Enterprise редакции Visual
Basic).
RDO
RDO был разработан специально для работы с удаленными или,
иначе говоря, серверными базами данных. Он позволяет легко
строить
и
выполнять
запросы
и
умеет
манипулировать
разнообразными результатами выполнения запросов, включая такие,
которые являются результатом работы хранимых процедур и могут
быть возвращены в виде параметра. С помощью RDO можно
создавать локальные курсоры, работать отдельно с результатами
запросов и связями. Производительность RDO в большинстве случаев
сопоставима с производительностью ODBC API.
RDO позиционируется как единственный быстрый способ
создавать эффективные и сложные клиентские приложения или
просто отдельные компоненты для работы с источниками данных. Не
теряя в производительности по сравнению с ODBC API, вы
выигрываете во времени, необходимом для кодирования. Время
можно также экономить, используя, например, Query Connection
Designer, чтобы оценить производительность работы любых типов
запросов или хранимых процедур, которые могут потребоваться в
вашем приложении, а также производительность методов нового
объекта UserConnection.
RDO поддерживает новую библиотеку пакетных курсоров,
написанную командой, создающей FoxPro. Это означает, что
появилась
возможность
создавать
очень
производительные
локальные курсоры и при необходимости работать с ними независимо
от наличия связи с базой. А в тот момент, когда необходимо обновить
данные, следует привязать объект rdoResultset к связи и выполнить
метод пакетного обновления данных.
RDO поддерживает асинхронную работу с данными и может
управляться событиями. Это означает, что, в отличие от первой
версии RDO, более нет необходимости проверять, завершилась ли
операция, т. к. в момент ее удачного или неудачного завершения
возникнет соответствующее событие. Очевидно, что при этом
наилучшим способом используются ресурсы операционной системы и
ее возможности по управлению несколькими потоками. И, более того,
RDO 2.0 позволяет создавать многопоточные компоненты,
выполняющиеся на сервере.
С появлением Visual Basic 5.0 арсенал разработчиков,
использующих RDO, пополнился новым оружием — проектировщиком
(или мастером) запросов (Query Connection designer). Он позволяет
создавать объекты класса UserConnection на этапе проектирования.
Подобные объекты имеет смысл создавать для того, чтобы собрать
воедино все свойства и параметры, необходимые для установления
коннекта и выполнения одного или нескольких запросов. Создав один
раз подобный объект, его можно использовать в нескольких
приложениях, просто включая в их состав соответствующий DSRфайл. Открывается данный объект простым вызовом метода без
параметров. Каждый из относящихся к нему запросов вызывается в
виде метода с параметрами. Использование подобной технологии
существенно уменьшает количество кода, которое необходимо
написать для вызова сложных хранимых процедур или выполнения
комплексных запросов. Существует связь между мастером и MS
Query, так что запросы можно создавать интерактивно. И, безусловно,
можно использовать запросы, созданные при помощи Microsoft Visual
Database Tools. А менеджер объектов Microsoft Visual Component
Manager поможет распространить созданный объект между всеми
членами команды разработчиков.
RDO следует рассматривать как основной инструмент обработки
данных при работе серверами типа Microsoft SQL Server, Oracle или
любой реляционной базой данных, для взаимодействия с которыми
имеется соответствующий ODBC драйвер, независимо от уровня его
реализации. Причем, создавая приложения, использующие RDO
сегодня, завтра их можно будет легко адаптировать для
использования механизма ADO, который вот-вот заменит RDO.
ADO
В чем основное достоинство ADO? В том, что ADO отражает
пожелания разработчиков иметь одну общую программную модель
для работы с данными и тем самым избавиться от необходимости
выбирать между DAO, RDO и другими программными интерфейсами.
ADO не является некоторой «специфичной» реализацией интерфейса
для работы с источниками данных, типа RDO или DAO. Это —
программная модель. Реализаций же может быть множество.
Примером может служить поставляемая в составе IIS реализация
программной модели ADO на основе OLE DB. В ближайшем будущем
можно ожидать появления расширений ADO, обеспечивающих
функциональность, характерную для других источников данных, таких,
например, как Jet.
ADO разрабатывался специально для того, чтобы заменить
собой все другие интерфейсы взаимодействия с данными. Т. е. ADO
не разрабатывался специально для реляционных или ISAM типов баз
данных, а с целью создания объектного интерфейса к любым
источникам данных — уже известным и определенным сегодня и тем,
которые могут появиться в будущем. Таким образом, ADO сегодня
может взаимодействовать как с реляционными базами, так и с ISAM,
текстовыми, иерархическими и любыми другими типами данных.
Единственное требование — наличие соответствующего провайдера.
ADO построен на основе некоторых ключевых функций, которые
необходимы для взаимодействия со всеми известными на сегодня
источниками данных. К набору этих функций могут добавляться
функции, свойственные специфичным источникам данных. Та версия
ADO, которая существует в настоящий момент, создана для
взаимодействия с основными источниками данных, для которых уже
существует OLE DB-провайдеры, включая OLE DB-провайдер,
известный
под
именем
«Kagera»,
которые
обеспечивает
взаимодействие OLE DB и ODBC. Данная реализация ADO впервые
была представлена в Internet Information Server (IIS), где этот
механизм работает в тесной взаимосвязи с Active Server Pages. Он
также поставляется (бесплатно и в свободно редистрибутируемом
виде) в составе OLE DB SDK.
Когда имеет смысл использовать ADO?
Проблема, которая для многих разработчиков сродни проблеме
Гамлета — использовать или нет программную модель ADO, является
довольно сложным вопросом. И вот почему. Во-первых, в настоящий
момент ADO не входит в состав Visual Basic 5.0. Это, однако, не
означает, что Visual Basic не может работать с ADO. Это означает
только, что пока реализация механизма ADO несколько недостаточна
для включения его в состав пакета. Естественно, что ADO появится
уже в ближайшем выпуске Visual Basic, а может и ранее на Webсервере Microsoft.
Планируется, что функциональность и производительность ADO
будет лучше, чем у DAO и RDO (и, более того, у VBSQL и ODBC),
однако пока это все не реализовано. Первая версия ADO по сути
представляет собой только подмножество функциональности RDO
2.0. Так, например, в нем отсутствуют следующие характеристики,
которые имеются в RDO 2.0:
— события, генерируемые ядром (Engine) и объектами типа
Connection, Resultset, и Column;
— возможность выполнения асинхронных операций;
— реализация запросов в качестве методов;
— расширенная обработка ошибок и непредвиденных ситуаций в
командном режиме;
— тесная интеграция с Visual Basic- как в проектировщике
запросов (Query Connection designer), так и в отладчике языка TSQL.
Однако следующая версия ADO (версия 2.0) призвана превзойти
функциональность RDO 2.0 и обеспечить гораздо более насыщенный
интерфейс — в дополнение к легкой программной модели. При этом
следует иметь в виду, что программировать непосредственно OLE DB
на Visual Basic весьма неудобно.
Как уже упоминалось, впервые программная модель ADO была
реализована в составе IIS. Это, тем не менее, не означает, что ADO
так останется только в этих рамках. ADO становится объектной
моделью
общего
назначения
для
всех
инструментов
программирования источников данных. А для тех, кто использует
Visual Basic, механизм ADO является воистину стратегической
моделью для обработки данных и призван заменить собой все прочие
интерфейсы.
Группа разработчиков Microsoft, создающая Visual Basic,
работает в тесном сотрудничестве со всеми командами,
реализующими новые технологии обработки данных, такие как ADO,
ADC и OLE DB. И по мере утверждения планов по разработке новых
технологий, команда Visual Basic выбирает те из них, которые
наилучшим образом могут использоваться из Visual Basic.
Так как ADO состоит из COM-компонент, это означает, что любое
приложение или язык программирования, способный работать с COM
объектами, может использовать данный механизм — включая,
разумеется, и Visual Basic. В настоящий момент не существует
никаких лицензионных ограничений на применение ADO. В любом
случае, если вы начинаете проект с нуля, имеет большой смысл
начать использовать ADO. Ведь в будущем будет гораздо проще
перейти от ADO 1.0 к ADO 2.0, вместо того, чтобы писать на RDO 2.0
сегодня и конвертировать в ADO 2.0 завтра.
OLE DB
ODBC представляет собой гетерогенный способ доступа к
реляционным данным, тогда как OLE DB — это гетерогенный доступ к
гетерогенным же данным. Таким образом, OLE DB призван сыграть
роль интерфейса к бесконечному разнообразию типов источников
данных, а не только просто к ISAM или реляционным СУБД, таким,
как, например, DAO или ODBC. ODBC основывается на языке SQL,
который, по сути, и определяет его функциональность и реализует
доступ к источникам данных. OLE DB основан на объектной модели,
отображающей только общие идеи организации источников данных.
Для разработчиков, использующих Visual Basic, проблема состоит в
том, что OLE DB напрямую недоступна из Visual Basic. Решает эту
проблему, как уже говорилось, ADO, поставляя основанный на COM
интерфейс. Именно это свойство позволяет использовать OLE DB как
из
традиционных,
так
и
описательных
(scripting)
языков
программирования, подобных Visual Basic.
Совершенно очевидно, что проектировщики и разработчики
решений вовсе не горят желанием остановиться на полпути,
обнаружив, что очередная новая технология Microsoft решает их
проблемы
с
меньшими
трудозатратами
и
возросшей
функциональностью и производительностью приложений. Именно
поэтому и именно сейчас необходимо отдавать себе отчет, что в
ближайшем будущем механизм ADO будет призван сыграть ключевую
роль в обработке разнообразных данных. Поэтому, приступая к
долгосрочному планированию, имейте это в виду. В настоящий
момент ADO только создается, хотя уже сейчас очевидно, что он
унаследует всю мощь RDO 2.0.
Таким образом, если вы заняты проектированием новой
системы, проанализируйте текущую версию ADO на предмет его
пригодности, и если это возможно — работайте с ним. Если же нет —
в вашем распоряжении RDO для любых реляционных источников
данных или DAO для ISAM типов данных.