Компоненты-оболочки для Services API
Лекция 8
InterBase Express
закладка InterBase в палитре компонентов представляет собой набор компонент под общим названием InterBase Express или IBX. Это компоненты для работы с базами данных InterBase, которые используют прямое InterBase API, т. е. обращаются к серверу непосредственно, без каких-то промежуточных (middle-ware) средств.
Фактически если разрабатывать приложения баз данных с использованием IBX, то для работы таких приложений нужно лишь наличие GDS32.DLL на диске в доступном месте.
Официально разработка IBX ведется в рамках IPL - InterBase Public License, т. е. компоненты доступны в полных исходных текстах и вы можете использовать их совершенно бесплатно. Однако фактически данные компоненты разрабатываются только сотрудниками корпорации Borland, совместимы только с определенными версиями и редакциями Delphi и C++ Builder и недоступны для публичной разработки, как это принято в обычных Open Source-проектах.
Компоненты IBX позволяют разрабатывать приложения, ориентированные на идеологию и архитектуру InterBase. К особенностям IBX можно отнести:
* явное управление транзакциями;
* поддержке расширений InterBase 6.0-7.0;
* поддержку event-alerters;
* использование генераторов для значений ключевых полей;
* управление сервером через Services API;
* поддержку стандартных и сторонних визуальных компонентов отображения данных;
* поддержку встроенных и сторонних генераторов отчета;
* совместимость с Delphi 5-7, C++ Builder 5-6 и Kylix
|
|
|
Общее описание основных компонентов, включенных в состав IBX
Компонент IBDatabase выполняет подключение к базе данных, все остальные компоненты вкладки соединяются с БД через него.
Все действия с базой данных происходят на уровне транзакций, компонент IBTransaction как раз обеспечивает такую транзакцию. В приложении обязательно должен быть хотя бы один IBTransaction, соединенный с IBDatabase. В сложных многозвенных базах данных таких транзакций может быть несколько. Вообще, имеется возможность для каждого набора данных (IBTable или IBQuery) использовать собственный компонент IBTransaction с различными настройками. Однако делать так не рекомендуется. Обычно наборы данных разделяют на группы, например, НД только для чтения, НД только для записи, НД для чтения/записи с мягкими или жесткими условиями соединения (об этом в следующих лекциях). В этом случае для каждой группы наборов данных выделяют свой компонент IBTransaction.
Компоненты IBTable и IBQuery почти ничем не отличаются от простых Table и Query.
Итак, выделите компонент IBDatabase. Через его свойство DatabaseName найдите и подключите файл First.gdb. Далее откройте свойство Params (откроется окно редактора). В окне впишите следующие параметры:
username=sysdba password=masterkey lcctype =win1251
|
|
|
Обратите внимание на то, что пробелы перед и после знака "=" недопустимы. Все слова можно вводить маленькими буквами. Каждый параметр указывайте на новой строке. Нажмите кнопку ОК и закройте окно редактора параметров. Свойство LoginPrompt переведите в False, а свойство Connected в True - связь с БД установлена. В сетевом варианте обычно LoginPrompt оставляют True, чтобы знать, какой пользователь на самом деле вошел в базу данных.
Далее выделите компонент IBTransaction и в его свойстве DefaultDatabase выберите нашу БД IBDatabasel.
Затем выделите таблицу IBTablel, переименуйте ее в TTovar (свойство Name), в свойстве Database выберите IBDatabasel. При этом в свойстве Transaction таблицы автоматически должен появиться компонент транзакций IBTransactionl. Если по каким то причинам этого не случилось, выберите его вручную. В свойстве TableName установите таблицу Tovar, а свойство Active переведите в True -таблица открыта.
Теперь выделим запрос IBQueryl. Свойство Name переименуем в Q1, в свойстве Database выберем IBDatabasel. И у этого компонента в свойстве Transaction автоматически должна появиться транзакция IBTransactionl.
Осталось только связать DataSource с таблицей TTovar, а сетку и навигатор - с DataSource. Код нажатия на кнопку такой же, как в предыдущих примерах.
Как видите, работа с различными механизмами доступа к серверу InterBase отличается лишь в деталях. Механизм IBX отличается тем, что в приложении обязательно должна быть хотя бы один компонент транзакций. Но в реальной практике таких компонентов может быть несколько, каждый из них обычно имеет свои настройки, а различные наборы данных могут подключаться к различным компонентам транзакций.
|
|
|
TIBDatabase - предназначен для подключения к базе данных. Основные методы: Open, Close.
TIBTransaction - предназначен для явного управления транзакцией. Основные методы: StartTransaction, Commit, Rollback, CommitRetaining, RollbackRetaining.
TIBTable - аналог стандартного TTable. Компонент предназначен для получения данных из одной таблицы или представления базы данных. Основное свойство - TableName. Основные методы: Open, Close. Набор данных, полученных при помощи TIBTable, является редактируемым, если речь идет о таблице базы данных или обновляемом представлении. Компонент совместим с визуальными компонентами.
TIBQuery - аналог стандартного TQuery. Компонент предназначен для получения данных на основе SQL-запроса. Этот набор данных не всегда будет редактируемым, зачастую необходимо использовать дополнительный компонент TIBUpdateSQL, чтобы иметь возможность редактировать полученные сведения. Основное свойство - SQL. Основные методы: Open, Close, ExecSQL. Компонент совместим с визуальными компонентами.
|
|
|
TIBDataSet - предназначен для получения и редактирования данных, является потомком стандартного класса TDataSet и полностью совместим со всеми визуальными компонентами. Основные методы: Prepare, Open, Close, Insert, Append, Edit, Delete, Refresh.
TIBStoredProc - предназначен для выполнения хранимых процедур и получения набора данных на основе результатов выполнения процедуры. Получаемый набор данных является нередактируемым. Компонент совместим с визуальными компонентами. Основное свойство - StoredProcName. Основной метод - ЕхесРгос.
TIBUpdateSQL - аналог TUpdateSQL. Используется в паре с TIBQuery и предназначен для создания модифицируемых наборов данных. Основные свойства: DeleteSQL, InsertSQL, ModifySQL и RefreshSQL.
TIBSQL - предназначен для выполнения SQL-запросов. В отличие от TIBQuery или TIBDataSet, TIBSQL не имеет локального буфера для набора данных и несовместим с визуальными компонентами.
TIBDatabaselnfo - позволяет получить системную информацию о некоторых свойствах базы данных, соединения и сервера. Например, UserNames - список пользователей, подключенных к базе данных, PageSize - размер страницы базы данных.
TIBSQLMonitor - предназначен для перехвата и отслеживания всех запросов, которые выполняют приложения, использующие ШХ.
TIBEvents - предназначен для получения пользовательских событий InterBase. Основное свойство - Events. Основные методы: RegisterEvents, UnresisterEvents.
Компоненты-оболочки для Services API
TIBConfigService - предназначен для настройки параметров базы данных.
TIBBackupService предназначен для создания резервных копий (backup) баз данных.
TIBRestoreService - предназначен для восстановления базы данных из резервной копии.
TIBValidationService - предназначен для проверки целостности базы данных и согласования внутренних данных о транзакциях.
TIBStatisticalService - предназначен для получения статистики о базе данных.
TIBLogService - предназначен для создания и просмотра лог-файла работы сервера.
TIBSecurityService - предназначен для редактирования списка пользователей на сервере.
TIBLicensingService - предназначен для добавления и удаления сертификатов, регулирующих количество и свойства клиентских подключений к серверу InterBase.
TIBServerProperties - предназначен для получения информации о сервере, параметров конфигурации и т. д.
ТIBInstall - предназначен для установки InterBase installation-компонента.
TIBUnlnstall - предназначен для установки InterBase un-installation компонента.
Иерархия компонентов в IBX
TIBTable
Компонент TIBTable прячет все указанные выше свойства, а вместо этого пользователю предоставляется свойство TableName. Пользователь указывает имя таблицы в свойстве TableName, а компонент автоматически формирует набор "спрятанных" запросов. Например, для таблицы с именем Table1 запрос в SelectSQL будет иметь вид:
SELECT * FROM Table1
Легко представить, что в нашей таблице несколько миллионов записей и этот запрос попытается получить их их в полном объеме на клиента. Например, при вызове Locate, который так любят пользователи BDE, если запись, соответству- ющая условиям поиска, не найдена в загруженном наборе записей, то TIBTable будет запрашивать оставшиеся записи, пока не найдется подходящая запись или пока не закончатся записи в таблице. Очевидно, что это вызовет колоссальную нагрузку на SQL-сервер и клиента, особенно в многопользовательской среде. Ни один специалист не рекомендует использование компонента TIBTable в реальных программных проектах, пред- назначенных для управления серьезными базами данных в многопользователь- ской среде.
TIBQuery
Аналогично TIBTable-компонент TIBQuery скрывает запросы для получения и редактирования данных. Вместо скрытого в этом компоненте свойства SelectSQL разработчику предлагается использовать свойство SQL. На самом де- ле после присвоения свойства SQL компонент присваивает его значение свой- ству SelectSQL. Но самое примечательное с точки зрения проектирования классов начинается тогда, когда мы хотим сделать наш запрос редактируемым (live-query). Поскольку свойства DeleteSQL, InsertSQL и ModifySQL спрятаны, то TIBQuery сам по себе не может предоставить разработчику редактируемые запросы. Однако, как уже было сказано, TIBQuery был сделан как аналог TQuery и для полной аналогии в IBX введен компонент TIBUpdateSQL. Он содержит соб- ственные свойства DeleteSQL, InsertSQL и ModifySQL и может подключаться к TIBQuery. После чего TIBQuery начинает использовать свойства компонента TIBUpdateSQL для редактирования собственных данных! Получается, что гото- вую функциональность TIBCustomDataSet, уже заложенную в него с самого начала, приходится дублировать в отдельном компоненте. Отметим, тем не менее, что в данной связке имеется несомненный смысл, если речь идет о миграции готовых BDE-приложений на IBX. В общем-то, вероятно, только ради этого дан- ные классы и были введены.
Мы можем принять это как выгоду с точки зрения замены старых BDE-компонентов на нечто похожее из IBX, однако, если вы пишете новое при- ложение, которое с самого начала базируется на IBX, мы бы рекомендовали вам использовать TIBDataSet как вместо TIBTable, так и вместо TIBQuery. Некоторые разработчики используют TIBQuery для выполнения только мо- дифицирующих запросов, т. е. тех, которые не возвращают результата. Напри- мер, это может быть запрос с предложением INSERT или DELETE. Для выполнения запросов, не возвращающих результирующий набор данных, в TIBQuery предусмотрен метод ExecSQL. Но фактически, как видно из исход- ных текстов компонента, вызов данного метода не отличается от вызова метода Open, который унаследован от TIBCustomDataSet. Поэтому для выполнения запросов, которые не возвращают результатов (в том смысле, что не возвращают набор результирующих строк), не имеет смысла исполь- зовать компоненты, предназначенные для взаимодействия с визуальными db-aware- компонентами. Вместо этого лучше использовать компонент TIBSQL, который не буферизует получаемые данные и предназначен именно для простого и быстрого выполнения SQL-запросов, в частности не возвращающих набор строк.
TIBStoredProc
Данный компонент предназначен для выполнения исполняемых (executed) хранимых процедур. Он также является потомком TIBCustomDataSet и полно- стью совместим с визуальными компонентами. Являясь прямым наследником TIBCustomDataSet, компонент TIBStoredProc прячет все основные свойства предка и добавляет такое свойство, как ProcedureName. Следует понимать, что в данном случае слово "прячет" относится больше к идеологии проек- тирования классов, нежели к технической стороне дела. Очевидно, что спрятать свойства предка в Object Pascal нельзя. TIBCustomDataSet уже имеет все необходимые свойства, кото- рые уже готовы для публикации, их просто не вынесли в секцию published. И хотя мы согла- симся, что в данном случае нельзя однозначно сказать, насколько правильным является дан- ное проектирование классов, однако считать его красивым довольно трудно. В результате указания названия процедуры (например, proc1) компонент сформирует SQL-запрос следующего вида: EXECUTE PROCEDURE Proc1 В целом возможно, что проще вызвать хранимую процедуру с помощью со- ответствующего SQL-запроса, используя TIBDataSet, если мы хотим показать результат в db-aware-компонентах, или TIBSQL, если мы хотим вызывать хра- нимую процедуру вида executable (т. е. не возвращающую набор данных). Единственным преимуществом использования TIBStoredProc по сравнению с TIBDataSet является тот факт, что TIBStoredProc самостоятельно формирует список параметров процедуры по ее имени, обращаясь к системным таблицам.
Книга
Дата добавления: 2019-11-25; просмотров: 114; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!