VB 6.0: доступ к данным с помощью технологии ADO
Часть 1. ADO идет на смену DAO и RDO
Часть 2. Переход от DAO к ADO: это вполне реально
Объекты ADO требуют нового подхода
Уникальные функции объектов ADO
Часть 1. ADO идет на смену DAO и RDO
DAO, ADO, RDO... Все это похоже на какую-то игру слов, где присутствует два ключевых понятия: данные и объекты. (Data Access Objects — объекты доступа к данным, ActiveX Data Objects — ActiveX-объекты работы с данными, Remote Data Objects — объекты удаленных данных.) На самом же деле речь здесь идет о разных технологиях доступа к данным (см. врезку «Сравнение ADO, DAO и RDO»), которые имеют не только разные внутренние механизмы, но и, что, может быть, гораздо важнее для прикладного программиста, разные перспективы на будущее.
DAO и RDO известны уже достаточно давно, и появление двух разных механизмов было связано с необходимостью оптимизации решения двух отдельных задач: доступа к локальным и удаленным базам данных соответственно. Однако естественное развитие вычислительных систем привело к необходимости создания единого механизма, который обеспечил бы единый подход при работе с БД различных классов.
В результате несколько лет назад Microsoft предложила в качестве единого интерфейса для доступа к локальным и удаленным данным новую технологию ADO, которая сегодня является частью архитектуры Microsoft Universal Data Access (MUDA)1.
 |
|
ADO 2.0 и новшества VB 6.0
Основой MUDA является OLE DB — низкоуровневый программный COM-интерфейс доступа к данным, который представляет собой развитие идеологии ODBC. Однако если ODBC предназначен для работы с реляционными базами данных (Access, DBF, SQL и др.), то OLE DB предлагает единообразный метод доступа к данным, хранящимся в разных источниках информации, в том числе и в нереляционных БД (например, в папках систем электронной почты или в простых файлах), обеспечивая при этом поддержку работы с наборами данных и иерархическими наборами записей, неподключенными постоянно к сети.
Поставщиками таких данных (OLE DB Provider) могут быть любые источники (в том числе приложения), написанные в соответствии со спецификациями OLE DB. Так, доступ к базам данных ODBC выполняется с помощью OLE DB Provider for ODBC.
ADO представляет собой прикладной объектный интерфейс более высокого уровня, который упрощает доступ к средствам OLE DB разработчикам, использующим языки высокого уровня. В 1998 году Microsoft выпустила модернизированный вариант ADO 2.0, который был впервые включен в состав в Visual Studio 6.0, и его автономных средств, в том числе VB 6.0.
ADO 2.0 представляет собой набор объектов, краткое описание которых приведено в табл. 1. VB-разработчик может работать напрямую или с помощью специальных средств, включенных в пакет. В первую очередь это новые элементы управления, функционирующие на основе OLE DB: ADO Data (является примерным аналогом уже известных элементов управления Data и Remote Date), DataGrid (DBGrid), DataList (DBList) и DataCombo (DBCombo).
Кроме того, VB 6.0 включает два новых инструмента работы с базами данных на основе OLE DB: конструктор Data Environment для установления связи с базами данных и создания отчетов, а также окно Data View для просмотра баз данных. (Мы уже подробно рассматривали эти средства в статье «Использование конструктора VB 6.0 Data Environment», КомпьютерПресс № 2’99, с. 140-144.) Следует также отметить, что VB-программист может создавать собственные поставщики данных OLE DB с помощью модуля классов (мы предполагаем рассмотреть этот вопрос в будущем).
Для использования ADO в VB-приложении нужно установить ссылку к библиотеке Microsoft ActiveX Data Objects Library 2.0 с помощью команды Project|References. Обратите внимание, что возможности ADO 2.0 доступны и при работе в среде VB 5.0. Для этого нужно установить на компьютер комплект MS Data Access Components, который можно загрузить, в частности, с узла http://www.microsoft.com/data/download.htm. Однако вы не сможете использовать элементы управления VB 5.0 совместно с элементом управления ADO Data. Впрочем, при желании можно воспользоваться компонентами независимых разработчиков, в том числе свободно распространяемых (например, по адресу: http://www.isgsoft.com).
|
|
DAO, RDO, ADO. Что выбрать?
Итак, теперь VB 6.0 поддерживает три различные технологии работы с базами данных. Очевидно, что каждая технология имеет свои плюсы и минусы и выбор нужного инструмента определяется спецификой задачи, а также квалификацией и навыками разработчика. Мы уже не раз подчеркивали, что эффективность конкретного применения инструмента определяется не только (или даже не столько) его внутренним совершенством, но и умением программиста работать с ним.
Тем не менее стоит упомянуть о результатах тестирования производительности разных методов доступа к данным, приведенным в статье «VS 6.0 Benchmarks: New Features Don’t Impact Speed» в журнале VBPJ (табл. 2). Там говорится об исследовании скоростных характеристик разных средств, входящих в состав Visual Studio 6.0, а также VB 5, для различных режимов работы программ (графика, математические задачи, обработка строк и пр.), в том числе и при работе с базами данных.
По результатам тестирования при работе с удаленными данными быстродействие ADO и RDO примерно одинаково. Что же касается локальных баз данных, то скорость ADO в 3-5 раз ниже, чем у DAO. Это, конечно, не очень здорово, но следует учитывать, что универсальный механизм всегда уступает специализированным, имея в качестве преимущества упрощение процесса разработки. (Современный стиль разработки заключается именно в таких приоритетах: главное — сократить трудоемкость разработки, а уже потом думать о повышении эффективности приложений. Можно осуждать подобный прагматизм, но факт остается фактом.)
Более важным является другой момент: Microsoft объявила, что будет совершенствовать и обновлять только модель ADO (что соответствует общей стратегии корпорации на унификацию разных технологий на базе ActiveX), то есть DAO и RDO постепенно должны сойти со сцены.
Вывод из этого очевиден: если сейчас вы используете DAO или RDO для доступа к данным, то в конце концов вам, вероятно, придется совершить этот переход к ADO в новых разработках. Но когда это лучше сделать? С одной стороны, лучше раньше, чем позже. С другой — торопиться не надо. Здесь следует отметить еще два важных момента.
Многие VB-эксперты указывают на недостатки существующей сегодня версии ADO. Если не принимать во внимание снижение производительности2, то главный упрек заключается в наличии довольно большого числа программных ошибок. В связи с этим эксперты журнала VBPJ советуют разработчикам дождаться выхода ADO 2.5. Впрочем, классический принцип освоения новых технологий говорит о том, что их использование в реальных системах лучше начинать с версии 3.
Так что вопрос о том, когда переходить к ADO, решать вам, но готовиться к этому нужно уже сегодня.
|
|
Часть 2. Переход от DAO к ADO: это вполне реально
О чем пойдет речь дальше
Миграция от одной технологии к другой никогда не проходит безболезненно, и переход от DAO к ADO не является исключением. Вы не можете просто поставить переключатель или запустить имеющуюся под рукой утилиту, которая выполняет необходимые изменения в программном коде доступа к данным. Необходимо обдумать каждый фрагмент кода и провести миграцию вручную, шаг за шагом осуществляя перевод только одной порции кода. Такое преобразование требует от вас знания фундаментальных отличий между двумя моделями, так как оптимальное использование разных средств требует порой серьезной переработки программ на уровне алгоритмов.
Миграцию от одной технологии к другой осуществляют не потому, что это интересно и достаточно просто, а потому, что этого требуют стоящие перед вами задачи, которые открывают перспективы для будущего развития системы. Такова судьба разработчика ПО — постоянное движение и переход...
В этой статье мы покажем, как планировать свою стратегию миграции в контексте решения различных задач преобразования DAO в ADO. Расскажем о том, чем объектная модель ADO отличается от аналогичной модели DAO, и попробуем объяснить на примерах, как использовать эти различия для создания более эффективного кода. Кроме того, мы продемонстрируем, что следует делать в тех случаях, когда в ADO отсутствуют прямые эквиваленты основных функций DAO, а также как воспользоваться преимуществами новых функций ADO в целях получения более широких возможностей управления хранимыми процедурами и другими аспектами программирования баз данных.
Процесс преобразования следует начинать с изучения существующей объектной модели DAO-приложения и анализа методов, подлежащих изменению. Возможные варианты модификации можно сгруппировать в три категории в зависимости от наличия эквивалентных функций в DAO и ADO (табл. 3).
Категория 1 содержит элементы, для которых объекты DAO и ADO имеют аналогичные методы, поэтому реализация данных функций в ADO требует проведения лишь незначительных изменений.
Категория 2 включает функции объектов DAO, для которых не существует прямого эквивалента в объектах ADO. Однако это не означает, что вы не можете заново создать такую функцию в ADO, — просто делать это надо по-другому.
Категория 3 соответствует случаю, когда в ADO имеются функции, не существовавшие в DAO. С точки зрения проблемы миграции этот случай не является первоочередным: сначала нужно обеспечить работу уже реализованных алгоритмов. Однако здесь нужно помнить, что простая замена старых функций на однотипные новые может порой привести даже к снижению производительности приложения. Реальный эффект может быть достигнут именно за счет использования принципиально новых возможностей современных технологий, хотя для этого, может быть, понадобится структурная перестройка программы. В этом плане разработчик, даже если он сегодня использует DAO, серьезно упростит себе жизнь, если будет ориентироваться на будущий переход в ADO.
Однако наиболее распространенным и простым является случай, когда для функций DAO имеются аналогичные средства ADO. Поэтому мы сконцентрируемся в основном на этом типе преобразований, используя для прояснения деталей конкретные примеры. Тем не менее отсутствие прямого, «один-к-одному», эквивалента между DAO и ADO совершенно не означает, что в ADO нет функциональных возможностей, которые ранее присутствовали в DAO. Напротив, ADO содержит альтернативные методы для достижения ваших бизнес-целей — методы, как правило, более простые в использовании, более быстрые и более масштабируемые, особенно при работе с удаленными базами данных.
|
|
Операции поиска
DAO содержит ряд полезных функций, которых вам будет недоставать при миграции в ADO. Например, DAO включает пять методов поиска: FindFirst, FindLast, FindPrevious, FinfNext и Seek. Они очень полезны, но имеют ряд недостатков.
Во-первых, использование явных методов поиска записей довольно трудоемко, поскольку требует повторного написания одного и того же кода для каждого метода, которому затем передают один и тот же критерий. Во-вторых, они эффективно работают только с локальными базами данных; их использование при поиске на удаленных базах данных существенно снижает производительность программ. Именно поэтому ADO не включает эти команды в свою объектную модель, но предлагает другие средства для решения аналогичных задач.
Для операций поиска и перемещения по базе данных ADO применяют метод Find, который использует несколько параметров для воспроизведения многих функций из модели DAO, в том числе и пять перечисленных выше (рис. 1 и 2).
В этом и состоит характерное отличие ADO от DAO: новая модель содержит меньше объектов, но вместе с тем больше свойств, методов и аргументов. В результате объектная модель становится более понятной.
Возьмем, к примеру, метод Find объектов ADO. Он находит следующую запись в объекте Recordset, отвечающую определенному условию, а затем делает ее текущей записью. Этот метод используется для нахождения конкретной записи в объекте Recordset с помощью фразы Where в стиле SQL, заданной пользователем: Recordset.Find Criteria, SkipRecords, SearchDirection, Start.
Метод Find в ADO поддерживает четыре аргумента, но чаще всего ему требуется только один — Criteria. Остальные аргументы используют значения, предустановленные по умолчанию, если вы не задали для них значения в явном виде. Параметр Criteria задает критерий, который необходим для нахождения записи в объекте Recordset. Первый необязательный параметр, SkipRecords, задает величину типа Long, указывающую количество записей, которые следует пропустить при нахождении конкретной записи в объекте Recordset. По умолчанию данное значение устанавливается как 0 — это означает, что текущая запись не пропускается. Последующие вызовы метода Find устанавливают используемое по умолчанию значение параметра SkipRecords как 1 — это означает, что нужно перейти на одну запись вперед, до тех пор пока не будет найдена следующая запись, отвечающая критерию поиска.
Третий параметр, SearchDirection, указывает направление, в котором должен осуществляться поиск, — вперед (0 или константа AdSearchForward) или назад (1 или AdSearchBackward), то есть обеспечивает функциональные возможности методов FindNext и FindPrevious в DAO. SearchDirection служит иллюстрацией того, как ADO «сплющивает» объектную модель DAO: один параметр позволяет заменить два метода поиска.
Последний параметр метода Find — Start, имеющий тип Variant и задающий место, с которого следует начинать поиск. Он представляет собой либо допустимую закладку, либо числовое значение закладки, которая определяет место, с которого начинается поиск: текущая (0 или AdBookmarkCurrent), первая (1 или AdBookmarkFirst) или последняя запись в объекте Recordset (2 или AdBookmarkLast).
Метод Seek выполняет самый быстрый способ адресации записи, а также изменения порядка поиска при изменении свойства Index объекта Table. Но Seek применим только к объекту Table, то есть его нельзя использовать при работе с динамическими наборами записей (dynasets). В то же самое время другие четыре метода поиска DAO применимы к объекту Recordset, а не к Table (вместо Seek используется комбинация FindFirst и FindNext).
В объектах ADO в качестве эквивалента Seek можно применять все тот же метод Find. Однако здесь следует подчеркнуть следующие моменты. Метод Find воспринимает только одно значение поиска, поэтому вы не можете выполнять несколько операций поиска с помощью операторов AND или OR. Это означает, что для выполнения подобной задачи в ADO следует применять несколько другой подход. К примеру, вы можете использовать свойство Filter объектов ADO, которое воспринимает несколько значений.
Свойство Filter меняет свой тип из String для объектов DAO в Variant для объектов ADO; тем не менее его основные функциональные возможности остаются неизменными. Свойство Filter устанавливает или возвращает величину типа Variant, которая содержит строковую переменную Criteria (состоящую из одной или нескольких фраз) и массив уникальных значений закладки, указывающие на записи в объекте Recordset.
|
|
Попробуем на примере
Конечно, теория — это одно, а написание кода — совсем другое. Предположим, что у нас есть некоторый код для объектов DAO, который выполняет несколько операций поиска (листинг 1), и мы хотим перейти к объектам ADO, сохранив неизменными критерий и механизм поиска. Начнем с того, что найдем все методы поиска объектов DAO. В первую очередь займемся методами FindFirst и FindNext, поскольку их легче всего преобразовать. Для их замещения применим метод Find объектов ADO с тем же самым критерием (листинг 2). Используем один из необязательных параметров этого метода, чтобы поиск осуществлялся в направлении вперед. Затем уничтожим свойство NoMatch, поскольку оно не существует в объектах ADO; вместо него напишем recordset.EOF. Это означает, что процедура поиска записей будет происходить до тех пор, пока не будет достигнут конец файла.
FindPrevious тоже легко преобразуется; для этого необходимо в методе Find установить направление поиска как обратное. И наконец, остается метод Seek, который не имеет прямого эквивалента в объектах ADO. Более того, разные разработчики используют его по-разному. Вы можете, например, решить заменить его методом Find. Такое решение в большинстве случаев является работоспособным, однако, если процесс поиска будет занимать слишком много времени, вам придется переписать код с целью его оптимизации.
Подход, который используется для поиска и нахождения записей в объектах ADO, является одним из наиболее критичных проектных решений. Вам может показаться утомительным ждать окончания поиска, особенно если вы уже знаете, какие данные, скорее всего, получите. Объекты ADO содержат альтернативные решения для таких случаев. Например, если вы собираетесь искать подмножества данных, то можно создать временную таблицу, содержащую только те строки и столбцы, которые, по вашему мнению, пригодятся в будущем. Проиндексировав ее, вы увеличите скорость доступа к данным. Следует также иметь в виду, что для разных методов доступа наиболее эффективными будут различные алгоритмы поиска.
|
|
Объекты ADO требуют нового подхода
Миграция от объектов DAO к объектам ADO в тех случаях, когда существуют аналогичные функции, является простой, хотя и требует много времени. Другие аспекты преобразования могут быть более сложными и занимать еще больше времени. Иногда процесс миграции может включать в себя несколько видов преобразований. Так, объект Properties существует как в DAO, так и в ADO, однако в последнем случае он служит иной цели. В DAO объект Properties используется из объекта Document для получения атрибутов базы данных Jet. А вот в ADO коллекция Properties служит для получения конкретной информации о следующих объектах: Connection, Recordset или любом другом.
Кроме того, вам необходимо уделить особое внимание транзакциям, которые попадают во вторую категорию (табл. 3). Объекты ADO поддерживают транзакции, но они реализуются совсем по-другому. Например, объект Workspace обеспечивает в DAO гибкое выполнение транзакций, которые охватывают несколько баз данных. Однако в ADO нет такого объекта, и поэтому вам необходимо реализовать другой механизм выполнения транзакций.
Категория 2 содержит множество операций DAO по работе с данными, и их преобразование в ADO может показаться сложным. Но можно упростить эту задачу, если вы не будете пользоваться функциями, относящимися к базе данных Jet. DAO содержит три объекта самого высокого уровня: DBEngine, Workspace и Database. В ADO вы заменяете все эти объекты на объект Connection, который управляет установлением связи с базой данных и созданием объектов Recordset (листинг 3).
Простой в использовании объект Connection позволяет связать потребителя данных с их провайдером. При этом нет необходимости создавать объекты связи в явном виде. Напротив, вы можете передать связь напрямую в объект Command или Recordset. Тем не менее создание объекта Connection в явном виде может увеличить производительность в тех случаях, когда вам необходимо совершить несколько «заходов», чтобы получить данные от провайдера. Аналогично вы можете заменить TableDefs и QueryDefs, входящие в DAO, на один объект Command из ADO. Этот объект позволяет обрабатывать операторы и запросы SQL, например хранимые процедуры, что объединяет всю работу с SQL в рамках одного объекта Command.
Объект Index в DAO определяет порядок просмотра записей таблиц баз данных. А метод OpenSchema позволяет получать информацию с помощью запроса типа перечисленных. В ADO у вас нет возможности создавать сами индексы, однако методы сортировки, входящие в метод Sort, и использование клиентского курсора могут дать указание ядру базы данных создать временный индекс для каждого поля. Тем не менее, если вы хотите создавать индексы в явном виде, необходимо самостоятельно обеспечить эту функциональную возможность (в виде SQL-оператора или хранимой процедуры).
|
|
Уникальные функции объектов ADO
Работа с функциями ADO, не входящими в DAO (категория 3), может быть как более простой, так и более сложной: все зависит от степени использования новых функций ADO. Например, можно поступить так, как делали многие программисты при переходе с VB3 на VB4: преобразовывать только базовые функции и методы, но ничего лишнего. Значительная часть разработчиков до сих пор пишет программный код в VB5 и VB6 точно так же, как они это делали в VB4, — избегая использования классов и возможности создавать элементы управления непосредственно в VB. Такой подход упрощает проведение преобразований и обеспечивает более высокий уровень поддержки со стороны Microsoft, но в то же самое время вы можете упустить новые важные функции. Не всегда имеет смысл выполнять что-либо по-старому, когда новые версии продукта предоставляют лучшие возможности.
Вы можете использовать новые функции объектов ADO, чтобы расширить возможности уже существующих приложений. Так, ADO содержит новые методы, обеспечивающие вывод сообщений, которые уведомляют вас о том, что процесс считывания набора записей завершен. Это означает, что теперь вам нет необходимости периодически проверять состояние набора записей. Кроме того, эти события можно использовать для выявления начала и прерывания связей, а также для поддержки транзакций, в случае если вам нужно отменить операцию.
Новые функции объекта Command в ADO предоставляют более широкие возможности управления хранимыми процедурами, упрощая тем самым выполнение подобных операций. Данный объект запускает одну команду, используемую для выполнения запросов, которые либо возвращают набор записей, либо нет. Эту команду можно также применять для создания готовых операторов, сохраняющих значения команды, которую вы хотите выполнить впоследствии, а также для уничтожения связи после выполнения оператора.
Наиболее значимые из новых возможностей ADO — «сплющенная» объектная модель и усовершенствованная масштабируемость доступа к локальным и удаленным базам данных — могут служить основополагающими причинами перехода от DAO к ADO. Последняя технология еще далека от совершенства — содержащиеся в ней в настоящий момент ошибки достаточно серьезны, — но она позволяет вам делать намного больше и с меньшими усилиями, особенно при доступе к удаленным данным. Однако эти усовершенствования не даются бесплатно — вам необходимо пересмотреть всю свою методологию при миграции к ADO. Примеры, приведенные в этой статье, являются лишь иллюстрацией наиболее типичных вопросов, которые следует решать при переводе программного кода. Выполнение такого преобразования требует больше, чем переработка кода вручную, — оно должно сопровождаться тщательным тестированием и использованием пошагового подхода. Прежде чем изменить всего одну строку кода, следует разработать стратегию всего преобразования (см. врезку «Разработка эффективной стратегии миграции»).
VBP-проекты примеров, приведенных в данной статье, вы можете найти на Web-узле по адресу: http://visual.2000.ru/develop/vb/source
КомпьютерПресс 7'1999
