Многоуровневая архитектура

Поясним материал на схеме:

Нажмите кнопку "ОК", окно Мастера создания удаленного модуля закроется, и у нас появится модуль данных MyRDM. Сохраните его на диск под именем RDM.

В этот контейнер с вкладки ADO поместите компонент ADOConnection и две таблицы ADOTable. Щелкните дважды по ADOConnection, чтобы открыть редактор подключений. Нажмите кнопку Build, чтобы открылся список поставщиков данных. Здесь выберем " Microsoft Jet 4.0 OLE DB Provider " и нажмем копку "Далее". В следующем окне, в поле 1 поместим адрес и имя файла (вы уже поместили файл по этому адресу?):

C:\DataBases\ok.mdb

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

Далее нажимаем "ОК" и закрываем редактор подключений. Свойство LoginPrompt компонента переведем в False, чтобы при подключении не выходило запроса на имя пользователя и пароль. А свойство Connected переведем в True, чтобы физически подключить компонент к базе данных.

Займемся табличными компонентами. В обеих ADOTable в свойстве Connection выберите наш ADOConnection1. У первой таблицы в свойстве TableName выберите таблицу LichData, а свойство Name переименуйте в TLichData. У второй таблицы в свойстве TableName выберите таблицу Telephones, а свойство Name переименуйте в TTelephones. Свойство Active обеих таблиц переведите в True, чтобы открыть эти наборы данных. Как видите, пока что подключение сервера к базе данных мало отличается от того, что мы проходили во второй лекции, при разработке локальной базы данных для отдела кадров. Однако дальше начинаются различия.

Как вы помните, посредником между НД и компонентами отображения данных является компонент DataSource. Однако в серверном приложении у нас нет компонентов отображения данных, поэтому компоненты DataSource для этого нам не нужны. Однако нам нужно будет организовать связь таблиц один-ко-многим, а для этого один DataSource нам все-таки понадобится.

Также нам понадобится посредник для связи с клиентским приложением, и этим посредником является компонент DataSetProvider, который находится на вкладке Data Access Палитры компонентов. Такой компонент требуется устанавливать к каждому набору данных ( Table или Query ), с которым будет соединяться клиентское приложение. Установите в контейнер MyRDM два таких компонента. У первого свойство Name переименуйте в DSPLichData, а в свойстве DataSet выберите таблицу TLichData. У второго свойство Name переименуйте в DSPTelephones, а в свойстве DataSet выберите таблицу TTelephones.

Теперь установим связь главная-подчиненная между таблицами, для этого установите один компонент DataSource. Его свойство Name переименуйте в dsLichData, а в свойстве DataSet выберите таблицу TLichData. Организация связи производится в таблице TTelephones. В ее свойстве MasterSource выберите dsLichData, затем раскройте сложное свойство MasterFields. Откроется окно редактора связи:

В разделе подчиненного поля выберите "Сотрудник", в разделе главного поля - "Ключ", нажмите кнопку Add, чтобы создать связь, и кнопку OK, чтобы подтвердить это. Внешний вид полученного контейнера представлен на рисунке ниже:

Это все, сервер приложений готов. Как видите, даже не пришлось подключать удаленный модуль данных к главной форме командой File -> Use Unit. Сохраните проект и командой Run -> Run (или кнопкой Run на панели инструментов) скомпилируйте и загрузите полученную программу. При этом произошли две вещи: проект скомпилировался в выполняемую программу, а при первом запуске наш сервер зарегистрировался в реестре Windows. Теперь Windows знает, где находится наш сервер, и при необходимости сможет его автоматически загрузить.

К слову сказать, при переносе серверного файла на другой ПК нет необходимости даже загружать эту программу, чтобы прописать ее в реестре Windows, достаточно из командной строки загрузить ее с параметром / regserver, при этом программа лишь пропишется в реестре и сразу отключится. А для удаления регистрации этого сервера из реестра нужно загрузить его с параметром / unregserver, например, так (у вас может быть другой адрес):

C:\ MyNewServer\ MyNewServer.exe /unregserver

Однако не забудьте, что для дальнейшей правильной работы он должен быть прописан в реестре Windows. Поэтому если сейчас вы удалили сервер из реестра, вновь загрузите программу MyNewServer.exe, чтобы заново прописать ее.

Как уже упоминалось, для правильной работы серверов DCOM на серверном ПК должна быть установлена и зарегистрирована библиотека midas.dll. В нашем случае этого делать не нужно, так как при установке Delphi библиотека устанавливается и регистрируется автоматически. Однако если вы будете использовать созданный сервер приложений на другом ПК, где не устанавливалась Delphi, то зарегистрировать библиотеку придется вручную. Для этого на вашем ПК нужно найти файл библиотеки, он устанавливается по адресу (для Windows XP ):

C:\Windows\System32

Этот файл нужно скопировать на ПК, который вы собираетесь использовать в качестве сервера, по этому же адресу. В этой же папке находится утилита regsvr32.exe, которая предназначена для регистрации библиотек *.dll. Чтобы зарегистрировать нашу библиотеку, надо из командной строки (или в окне команды Пуск -> Выполнить) вызвать утилиту, передав ей в качестве параметра имя библиотеки:

C:\Windows\System32\regsvr32 midas.dll

Таким образом, мы зарегистрируем библиотеку в реестре. Снять регистрацию можно командой:

C:\Windows\System32\regsvr32 /u midas.dll

Не снимайте регистрацию на вашем ПК, иначе потом вы не сможете загрузить сервер приложений!

Если в качестве источника данных вы будете использовать сервер InterBase, то набор компонентов в удаленном модуле данных, скорее всего, будет с вкладки InterBase, а их подключение к базе данных будет таким же, как мы изучали в прошлых лекциях.

Связь наборов данных сервера с клиентским приложением обеспечивается компонентом DataSetProvider, рассмотрим некоторые полезные свойства и методы этого компонента.

На следующей лекции мы подробно разберем создание клиентской части многоуровневых приложений.