Распределенные системы: технология Borland Midas. Часть 3. Фертиков В.В. - 16 стр.

UptoLike

Составители: 

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;