Технология Клиент-Сервер 1998'4
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

OLE DB: правильный выбор интерфейса

OLE DB определяет полный набор интерфейсов доступа к широкому спектру типов данных, содержащихся в различных хранилищах. OLE DB Programmer's Reference может испугать своим объемом, но ни одно из хранилищ данных не может обеспечить поддержку всего набора возможностей, описанных в этом справочнике. OLE DB-провайдеры данных всего лишь предоставляют интерфейсы, отражающие исходные свойства и возможности хранилищ данных. Базовый уровень функциональности поддерживается всеми провайдерами. Взаимодействие над этим базовым уровнем посредством реализаций общих дополнений — таких, как прокрутка (scrolling) или позиционирование, базирующееся на утверждении — обеспечивают общие обслуживающие компоненты, если провайдер не предоставляет такой поддержки.

Под минимальным уровнем поддержки, предоставляемым всеми хранилищами данных с общим набором дополнительных сервисов понимается:

• OLE DB-провайдеры данных легче писать. Им нужно только предоставить набор интерфейсов, отражающих исходный набор возможностей, что приведет к возможности получать через OLE DB расширенный диапазон данных.

• Приложения, работающие с OLE DB напрямую или через ADO, могут стать функциональнее, поскольку обслуживающие компоненты предоставляют больше возможностей, нежели хранилище данных.

Введение: OLE DB как компонентно-ориентированная технология

Чтобы предоставить доступ к данным всех типов в среде СОМ (Component Object Model — Объектно-компонентная модель), OLE DB спроектирована как компонентно-ориентированная технология. В OLE DB хранилища данных предоставляют интерфейсы, отражающие их изначальный набор возможностей. На основе этих интерфейсов для обеспечения более устойчивых моделей данных могут строиться общие компоненты. Компонентную архитектуру можно определить так: OLE DB определяет общие характеристики различных провайдеров данных и сервисов, а также определяет общие интерфейсы, которые отражали бы эти характеристики. Например, хотя набор строк (rowset) и может быть получен при помощи множества различных механизмов, результатом всегда будет набор строк с точно определенными интерфейсами, методами и характеристиками. Работа OLE DB с результатами составной таблицы не отличается от работы с результирующим текстовым файлом, содержащим табличные данные. Такое определение общих интерфейсов позволяет компонентам более эффективно расширять индивидуальную функциональность провайдера данных.

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

Потребители

Разработчики, пишущие приложения для работы с OLE DB, могут выбирать их уровень взаимодействия с провайдерами OLE DB. Такие приложения-потребители могут создаваться для использования определенного провайдера, причем в этом случае они проектируются с учетом функциональности конкретного провайдера. Либо, они могут создаваться для использования общих провайдеров. Работая с общим провайдером, потребитель может сделать следующее:

• Использовать минимальный набор возможностей и работать с провайдерами OLE DB.

• Использовать более высокий уровень функциональности, запрашивая у провайдера поддержку дополнительных возможностей.

• Использовать более высокий уровень функциональности, запросив реализацию утерянных средств у обслуживающих компонентов там, где эти компоненты доступны.

Таблица 1. Базовые интерфейсы потребителя

1.Эти интерфейсы всегда поддерживаются общими компонентами SDK. Непосредственно провайдерами они не реализуются никогда.

Функциональность базового потребителя

В таблице 1 приведен минимальный набор средств, на поддержку которого потребитель может рассчитывать при взаимодействии с любым OLE DB-провайдером. Эта таблица разбита на три столбца:

• Объекты - перечисляются OLE DB-объекты, поддерживающие интерфейсы или поведение.

• Базовые интерфейсы - перечисляются возможностидоступныепри работе с любым OLE DB-провайдером.

• Возможность обновления - перечисляется минимальныйнабор возможностей, доступный любому OLE DB-провайдеру, поддерживающему способность обновления данных . Провайдеры, не поддерживающие этого набора, считаются "read-only"-провайдерами .

Потребитель гарантированно получит описанные выше возможности одним способом из трех:

• Провайдеры данных, написанные в Visual Basic, Visual J++, C или C++ с применением OLE DB Simple Provider (OSP) Toolkit, автоматически поддерживают, как минимум, все приведенные выше свойства.

• Провайдеры данных, изначально написанные в С или С++, могут предоставлять полный набор интерфейсов, перечисленных в таблице 1.

• Провайдеры данных, изначально написанные в С или С++, могут реализовывать минимальный набор свойств провайдера, описанный в разделе "Минимальная функциональность провайдера". Реализацию дополнительных возможностей, необходимой для обеспечения основных свойств потребителя они обеспечивают с помощью обслуживающих компонентов.

Провайдеры

OLE DB-провайдеры предоставляют интерфейсы OLE DB для некоторых типов данных. Провайдеры OLE DB включают в текстовый файл или поток данных все из полной SQL-СУБД. Очевидно, что эти провайдеры данных обладают различной функциональностью, и важно эту функциональность не ограничивать. Но, в то же время, нецелесообразно ожидать от всех провайдеров, предлагающих простые табличные данные , реализации полнофункционального сервера запросов.

Провайдеры поддерживают исходные свойства предоставляемых ими данных. Как минимум, сюда входят возможности, , описанные в разделе "Минимальная функциональность провайдера". Дополнительные интерфейсы должны реализовываться как не противоречащие изначальным. Если изначально провайдер поддерживает всё, что перечислено в разделе "Функциональность базового потребителя", то обслуживающим компонентам не обязательно обеспечивать минимальный набор возможностей потребителя. В дополнение, провайдеры могут предоставлять интерфейсы для дополнительных возможностей , описанных в разделе "Расширенные интерфейсы".

Все провайдеры должны быть многофункциональными (apartment), временными (rental) или многопоточными (multithread), и должны поддерживать аггрегации объектов DataSource, Session и Rowset. При возможно, провайдеры должны поддерживать агрегации объектов Command и View.

Провайдеры должны поддерживать преобразование данных в типы, возвращаемые в IColumnsInfo::GetColumnsInfo или IColumnsRowset::GetColumnsRowset для столбцов rowset, и в ICommandWithParameters::GetParameterInfo для параметров, а также DBTYPE_WSTR для всех значений столбцов или параметров, отличающихся от тех, которые описаны как объекты. Провайдеры, поддерживающие привязку к объектам типа IStream или ILockBytes , должны поддерживать и привязку к их столбцам как ISequentialStreams.

Таблица 2. Интерфейсы провайдера с минимальной функциональностью

1. Для соответствия минимальным требованиям, предъявляемым провайдеру с возможностью обновления, для провайдеров OLE DB 2.0 поддержка IConnectionPointContainer для IRowsetNotify необязательна. Однако, обновляемые провайдеры обязательно должны поддерживать эту точку подключения, поскольку некоторые потребители будут вынуждены расценивать провайдеров, не поддерживающих нотификацию rowset выставлением точки подключения для IRowSetNotify, как провайдеров только для чтения.
Поддержка интерфейса означает поддержку всех методов этого интерфейса. При отсутствии методов возвращается E_NOTIMPL.
Поддержка свойства означает поддержку установок и соответствующего поведения всех возможных значений этого свойства.
Поддержка необходимых свойств rowset означает, что при указании любой комбинации свойств rowset результатом будет rowset, имеющий по меньшей мере эти свойства. Это не значит, что данные свойства всегда справедливы для любого rowset, если свойства не запрашивались пользователем.

1 Провайдер, поддерживающий свойство DBPROP_CANSCROLLBACKWARDS, должен поддерживать и свойство DBPROP_CANFETCHBACKWARDS.

Минимальная функциональность провайдера

Важно, чтобы при создании провайдера был реализован полный набор интерфейсов, относящийся к определенному типу данных. Для того, чтобы провайдер рассматривался как общий OLE DB-провайдер, он должен реализовывать, как минимум, интерфейсы и поведение, приведенные в Таблице 2. Провайдеры, реализующие минимальную функциональность, для реализации базовой функциональности потребителя (рис.1), могут рассчитывать на общие обслуживающие компоненты SDK.

Рис. 1. Базовое приложение для общения с провайдером с минимальной функциональностью использует сервисные компоненты.

Базовые провайдеры

Провайдеры, реализующие полный набор базовых интерфейсов, могут использоваться общими потребителями без поддержки дополнительных обслуживающих компонентов, что показано на Рис. 2.

Рис. 2. Базовое приложение общается с базовым провайдером напрямую

Провайдеры, реализующие возможности, приведенные в таблице 3, в дополнение к минимальной функциональности провайдера, используются как базовые провайдеры.

Таблица 4. Расширенные интерфейсы

1. Расширенная функциональность, которая может предоставляться провайдерами, поддерживающими работу с rowset.

3. Расширенная функциональность, которая может предоставляться провайдерами, поддерживающими поиск по индексу.

Расширенные интерфейсы

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

Помимо дополнительных интерфейсов, провайдеры могут поддерживать и определенные интерфейсы для::

• работы с rowset - предоставляется провайдерами, изначально поддерживающим возможность фильтрации и сортировки;

• команды - предоставляется провайдерами, выполняющими усложненные запросы или операторы ;

• транзакции - предоставляется провайдерами, которые могут поддерживать возможности работы с транзакциями ;

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

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

• Потребитель может запросить у общих сервисов реализовать расширенный набор возможностей, если такие обслуживающие компоненты доступны.

• Потребитель может реализовать дополнительный код, компенсирующий недостаток возможностей, в приложении.

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

• Потребитель может вернуть сообщение об ошибке, показывающее, что провайдер неспособен обеспечить необходимую функциональность.

Copyright © 1994-2016 ООО "К-Пресс"