ВУЗ:
Составители:
16
ницу Multitier и на ней необходимый тип TRemoteDataModule. Создание уда-
ленного модуля данных начинается с запуска мастера «Remote Data Module
Wizard» , где необходимо указать имя класса (CoClass Name), под которым дан -
ный сервер приложений будет зарегистрирован в реестре как OLE-сервер . За-
дадим , к примеру , имя DemoRDM. Согласно рассмотренной выше общей схеме
трехзвенного приложения, помещаем в созданным модуль данных нужное ко-
личество компонентов наборов данных и для каждого из них – по собственному
провайдеру (TDataSetProvider). В данном случае мы используем только
один компонент TQuery для доступа к данным и соответственно один провай -
дер . Для того чтобы их связать между собой , как показано на схеме, необходи-
мо установить значение свойства DataSet провайдера. Важно еще раз обратить
внимание на следующую особенность реализации провайдера: если требуется
управлять присоединенным к нему компонентом набора данных из клиентского
приложения, например путем передачи текста SQL-запроса, необходимо в
свойство Options провайдера включить значение poAllowCommandText. Для
нашего примера установка этой опции является обязательной .
Сами компоненты наборов данных (TDataSet) необходимо настроить на
доступ к соответствующей базе данных (в нашем случае – DBDEMOS). Посколь-
ку требований к обеспечению безопасности доступа к данным в нашем иллюст-
ративном примере не предъявляется, выберем наиболее простой способ на-
стройки (см . заключительный абзац раздела «Сервер приложений»): доступ к
данным для всех «тонких» клиентов организуем через единственный компо -
нент TDatabase, который мы с этой целью поместим на главной форме. Его
свойство AliasName установим равным DBDEMOS, а свойству DatabaseName
присвоим имя (например , demo), которое будет использоваться всеми компо -
нентами TDataSet в качестве имени используемой базы данных. Так в нашем
случае единственный компонент TQuery нужно соединить с TDatabase, уста-
новив значение его свойства DatabaseName соответственным образом.
Наконец, реализуем упомянутый счетчик подключенных клиентов . Его
работа основана на описанном выше механизме, при котором для каждого
«тонкого» клиента, подключенного к серверу приложений , создается новый эк-
земпляр удаленного модуля данных. Фактически, разрабатываемому серверу
необходим счетчик создаваемых во время выполнения удаленных модулей дан -
ных. Реализуем обработчики событий , связанные с созданием и уничтожением
удаленного модуля данных, которые будут отображать результат подсчета в
метке формы :
procedure TDemoRDM.RemoteDataModuleCreate(Sender: TObject);
begin
with Form1.Label1 do Caption:=IntToStr(StrToInt(Caption)+1)
end;
procedure TDemoRDM.RemoteDataModuleDestroy(Sender: TObject);
begin
with Form1.Label1 do Caption:=IntToStr(StrToInt(Caption)-1)
end;
16 ницу Multitier и на ней необходимый тип TRemoteDataModule . Создание уда- ленного модуля данных начинается с запуска мастера «Remote Data Module Wizard», где необходимо указать имя класса (CoClass Name), под которым дан- ный сервер приложений будет зарегистрирован в реестре как OLE-сервер. За- дадим, к примеру, имя DemoRDM. Согласно рассмотренной выше общей схеме трехзвенного приложения, помещаем в созданным модуль данных нужное ко- личество компонентов наборов данных и для каждого из них – по собственному провайдеру (TDataSetProvider ). В данном случае мы используем только один компонент TQuery для доступа к данным и соответственно один провай- дер. Для того чтобы их связать между собой, как показано на схеме, необходи- мо установить значение свойства DataSet провайдера. Важно еще раз обратить внимание на следующую особенность реализации провайдера: если требуется управлять присоединенным к нему компонентом набора данных из клиентского приложения, например путем передачи текста SQL-запроса, необходимо в свойство Options провайдера включить значение poAllowCommandText . Для нашего примера установка этой опции является обязательной. Сами компоненты наборов данных (TDataSet) необходимо настроить на доступ к соответствующей базе данных (в нашем случае – DBDEMOS). Посколь- ку требований к обеспечению безопасности доступа к данным в нашем иллюст- ративном примере не предъявляется, выберем наиболее простой способ на- стройки (см. заключительный абзац раздела «Сервер приложений»): доступ к данным для всех «тонких» клиентов организуем через единственный компо- нент TDatabase , который мы с этой целью поместим на главной форме. Его свойство AliasName установим равным DBDEMOS, а свойству DatabaseName присвоим имя (например, demo), которое будет использоваться всеми компо- нентами TDataSet в качестве имени используемой базы данных. Так в нашем случае единственный компонент TQuery нужно соединить с TDatabase, уста- новив значение его свойства DatabaseName соответственным образом. Наконец, реализуем упомянутый счетчик подключенных клиентов. Его работа основана на описанном выше механизме, при котором для каждого «тонкого» клиента, подключенного к серверу приложений, создается новый эк- земпляр удаленного модуля данных. Фактически, разрабатываемому серверу необходим счетчик создаваемых во время выполнения удаленных модулей дан- ных. Реализуем обработчики событий, связанные с созданием и уничтожением удаленного модуля данных, которые будут отображать результат подсчета в метке формы: procedure TDemoRDM.RemoteDataModuleCreate(Sender: TObject); begin with Form1.Label1 do Caption:=IntToStr(StrToInt(Caption)+1) end; procedure TDemoRDM.RemoteDataModuleDestroy(Sender: TObject); begin with Form1.Label1 do Caption:=IntToStr(StrToInt(Caption)-1) end;
Страницы
- « первая
- ‹ предыдущая
- …
- 14
- 15
- 16
- 17
- 18
- …
- следующая ›
- последняя »