Модель briefcase засобами MIDAS

Михайло Голованов

У минулому номері журналу я писав про реалізації моделі Briefcase за допомогою ADO. На відміну від ADO, засоби роботи з відключеними наборами даних у MIDAS були реалізовані з найпершої версії. Реалізація моделі Briefcase засобами MIDAS дещо простіше, хоча і тут є свої підводні камені.

Додаток MIDAS складається з двох частин: сервера додатків і тонкого клієнта. Сервер додатків «спілкується» з сервером БД (або іншим джерелом даних), реалізує бізнес-правила і надає тонкому клієнту дані за запитом. Функція тонкого клієнта - це відображення даних користувачеві.

Як приклад ми спроектуємо простий сервер додатків і тонкий клієнт для роботи з базою, описаної в попередньої частині статті. Сервер додатків реалізуємо як модуль MTS/COM +. Ніяких особливостей створення сервера додатків для моделі briefcase немає, тому я не буду описувати цей процес у деталях. У IDE Delphi створимо новий проект програми для MTS/COM +, вибравши пункт меню File/New/Other, і в що з'явилося, діалозі виберемо пункт ActiveX Library із закладки ActiveX. Потім включимо в проект новий видалений модуль даних (File/New/Other і пункт Transactional Datamodule із закладки Multitier).

У віддаленому модулі даних розмістимо наступні компоненти і встановимо значення їх властивостей згідно з таблицею 1, наведеною нижче.        

Компонент         

Властивість         

Значення             

Conn: TADOConnection         

ConnectionString         

Налаштувати на з'єднання з   БД             

adsParams: TADODataSet         

Connection         

Conn             

CommandText         

CommandText         

select * from Params             

dspParams: TDataSetProvider         

DataSet         

adsParams     

Таблиця 1

Відкомпілюйте проект сервера і встановіть отриману dll в нове MTS/COM +-додаток c ім'ям MIDAS_briefcase, за допомогою пункту меню Run/Install COM + Object.

Тонкий клієнт являє собою DeskTop-додаток. Для зв'язку з сервером додатків клієнт використовує один з компонентів типу Connection із закладки DataSnap (ми скористаємося DCOMConnection) та спеціальний DataSet - ClientDataSet.

У таблиці 2 наведені властивості, що впливають на роботу компонентів тонкого клієнта з сервером додатків, а також їх значення.        

Компонент         

Властивість         

Значення             

DCOMConn: TDCOMConnection         

ServerName         

Project1.MIDAS_bc                      

LoginPrompt         

false             

cdsParams: TClientDataSet         

RemoteServer         

DcomConn                      

ProviderName         

dspParams     

Таблиця 2

Зовнішній вигляд форми програми тонкого клієнта наведено на малюнку 1.

Малюнок 1

Отримання даних з центрального сервера

Отримання даних з сервера додатків аналогічно наведеним у прикладі для ADO. Код наведено нижче.        

procedure TForm1.act_RemoteConnectExecute (Sender: TObject);   

begin   

try   

with cdsParams do try   

Close;   

RemoteServer: = DCOMConn;   

FileName :='';   

Active: = true;   

except on E: Exception do   

MessageDlg (Format ( 'Помилка підключення до сервера:% s', [E. Message]),   

mtError, [mbOk], 0);   

end;   

finally   

DCOMConn.Close;   

end;     

Все просто, але для підключення до сервера треба не забувати скидати назва файлу кеша (властивість FileName) і закривати з'єднання з сервером після отримання даних.

Читання та запис даних з локального кеша

Для читання даних з локального кеша у ClientDataSet є метод LoadFromFile:        

procedure TForm1.act_ConnectLocalExecute (Sender: TObject);   

begin   

with cdsParams do   

begin   

RemoteServer: = nil;   

FileName: = ExtractFilePath (Application.ExeName)   + LocalFile;   

LoadFromFile (FileName);   

end;   

end;     

Для запису до локальний кеш - метод SaveToFile:        

with cdsParams do   

SaveToFile (ExtractFilePath (Application.ExeName)   + LocalFile);     

Знову ж ніяких сюрпризів.

Збереження даних на сервер, скасування зроблених змін

Для збереження даних на сервер призначений метод CilentDataSet-а ApplyUpdates. Параметр даного методу вказує макісімально допустиму кількість помилок при передачі даних на сервер.        

procedure   TForm1.act_SaveToServerExecute (Sender: TObject);   

begin   

if cdsParams.Active and   (cdsParams.ApplyUpdates (0) = 0) then   

act_RemoteConnect.Execute;   

end;     

При виникненні помилки генерується подія OnReconcileError. Обробка помилки здійснюється за допомогою стандартного модуля обробника помилки, підключити цей модуль в проект можна, вибравши ReconcileErrorDialog на закладці Dialogs (File/New/Other). Оброблювач OnReconcileError буде виглядати при цьому такий спосіб:        

procedure   TForm1.cdsParamsReconcileError (DataSet: TCustomClientDataSet;   

E: EReconcileError; UpdateKind: TUpdateKind;   

var Action: TReconcileAction);   

begin   

Action: = HandleReconcileError (DataSet,   UpdateKind, E);   

end;     

Для скасування внесених змін ClientDataSet містить метод CancelUpdates.

Читання даних "порціями"

Обмін даних між тонким клієнтом і сервером додатків відбувається пакетами. Пакет містить інформацію про метадані та/або набір записів. Цікавою можливістю MIDAS є передача даних «Порціями». Природно, ця можливість реалізується лише під час наявності з'єднання з центральним сервером. Включення даної можливості здійснюється установкою властивості FetchOnDemand ClientDataset-а в true. На жаль, навіть при цьому запит до сервера бази даних вибирає всі записи відразу. Про один із способів усунення цього недоліку я й хочу розповісти.

Перше, що необхідно зробити, це змінити текст SQL-запиту, що знаходиться у властивості CommandText компонента adsParams (нагадаю, що це ADODataSet), на наступний:        

select   Top 2 * from Params where ParamID>: ID     

При цьому записи будуть вибиратися порціями по 2. Природно, що в реальних додатках розмір пакета буде більше цього числа. Конкретне число являє собою компроміс між витратами часу на передачу пакета по мережі (чим більше розмір пакету, тим вище затримки при його передачі) і затримками, що виникають від частого звернення із запитами до сервера БД. (на практиці розмір такого пакету залежить від розміру запису, але в середньому становить від 30 до 250 рядків. - Прим.ред.)

Залишається вирішити проблему, як клієнт буде передавати серверу ідентифікатор останньої зчитаної записи (ParamID). Проблема ця виникає тому, що сервер додатків не зберігає стан між викликами клієнтів. З одного боку, це робить сервер додатків більш масштабованим, але з іншого, вимагає додаткового коду на стороні клієнта для зберігання стану.

Для передачі значення первинного ключа останньої прочитаної клієнтом записи можна використовувати подія BeforeGetRecords. Дане подія визначено для набору даних ClientDataSet на клієнті і компонента провайдера на сервері. Перед отриманням пакету із записами цю подію спочатку генерується на клієнта, а потім у провайдера на сервері додатків. Подія має параметр, який передається за посиланням OwnerData (типу OleVariant). Ось через цей параметр ми і будемо передавати значення ключа останнього запису. Код обробника в клієнтському додатку:        

procedure   TForm1.cdsParamsBeforeGetRecords (Sender: TObject;   

var OwnerData: OleVariant);   

begin   

if not   cdsParams.FieldByName ( 'ParamID'). IsNull then   

OwnerData: = cdsParams.FieldByName ( 'ParamID'). Value;   

end;     

Відповідно для провайдера на сервері додатків:        

procedure   TMIDAS_bc.dspParamsBeforeGetRecords (Sender: TObject;   

var OwnerData: OleVariant);   

begin   

if not VarIsNull (OwnerData) and not   VarIsClear (OwnerData) then   

adsParams.Parameters.ParamValues [ 'ID']: = OwnerData;   

end;     

Щоб ініціювати підкачки, необхідно обробляти ще одна подія об'єкта ClientDataSet - OnScroll:        

procedure   TForm1.cdsParamsAfterScroll (DataSet: TDataSet);   

begin   

if cdsParams.Eof then   

cdsParams.GetNextPacket;   

end;     

Виклик cdsParams.GetNextPacket; якраз і ініціює отримання наступного пакета даних.

Як з'ясувалося, код методу GetNextPacket містить помилку, що виражається у відмові читання наступного пакета після кількох спроб читання першого пакету. Пов'язано це з неправильним значенням змінної ProviderEOF в описаній вище ситуації.        

function   TCustomClientDataSet.GetNextPacket: Integer;   

begin   

CheckActive;   

if ProviderEOF then Result: = 0 else   

begin   

UpdateCursorPos;   

if (FPacketRecords = 0) and   FMasterLink.Active and   

(FMasterLink.Fields.Count> 0) then   CheckDetailRecords else   

begin   

AddDataPacket (DoGetRecords (FPacketRecords,   Result, 0,'', Unassigned),   

Result <> FPacketRecords);   

ProviderEOF: = Result <>   FPacketRecords;   

end;   

  Resync ([]);   

end;   

end;     

Виправлено це було явним присвоєнням ProviderEOF значення false перед виконанням перевірки if ProviderEOF then Result: = 0 else ... ...

Вищеописаний метод організації підкачки має, до жаль, один великий недолік - він буде працювати лише під час сортування набору даних на клієнті по первинному ключу. Однак не так складно доопрацювати його для обходу і цієї проблеми.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.rsdn.ru/