Використання моделі briefcase при розробці
додатків баз даних
Використання коштів ADO.
Михайло Голованов
Вимоги бізнесу щодо забезпечення роботи мобільних
користувачів
Впровадження інформаційних систем для автоматизації
діяльності бізнесу вимагає від розробників баз даних реалізації все нових
можливостей в розроблюваних ними додатках. Створення програмного
забезпечення, що дозволяє користувачам працювати лише в межах офісу, на
сьогоднішній день стає явно недостатньо. Співробітникам офісу потрібно
забезпечити доступ до інформаційних масивів фірми у відрядженні, з дому, з
офісу клієнта. При цьому користувачі хочуть не тільки переглядати дані, але й
мати можливість вносити до них зміни. Важливим вимогою з боку
адміністраторів інформаційних систем є простота установки і настройки
клієнтських додатків.
Підводячи підсумок вищесказаного, можна виділити основні
вимоги замовників до програмного забезпечення для мобільних клієнтів
інформаційної системи:
Можливість отримання даних, співробітниками поза
меж офісу фірми.
Можливість внесення мобільним клієнтом змін до
дані, які потім повинні бути синхронізовані з центральною БД.
Можливість роботи мобільного клієнта за відсутності
постійного каналу зв'язку з офісом.
Простота установки, настройки та експлуатації створених
додатків.
Технічні проблеми і варіанти реалізації
При реалізації вищезазначених вимог замовників
виникають наступні технічні проблеми:
Забезпечення зберігання отриманої користувачем
інформації в перервах між сеансами зв'язку з центральним офісом з можливістю
продовження роботи мобільного користувача. Іншими словами користувач не
повинен помічати відмінностей у роботі програми в режимах on-line та off-line.
Синхронізація зроблених користувачем змін з
центральною базою. Оскільки час між редагуванням запису мобільним
користувачем і внесенням її в центральну базу може становити дні, тижні і
навіть місяці застосування звичайного для моделі клієнт-сервер механізму блокувань
записів не має сенсу. При цьому кілька мобільних користувачів можуть
одночасно редагувати кожен свою копію даних з сервера, тоді при
спробі синхронізації даних неминуче виникнення конфліктів змін
внесених в одну і ту ж запис різними користувачами. Дані конфлікти --
це конфлікти синхронізації. Забезпечення засобів вирішення конфліктів
синхронізації-це одна з головних вимог до технічної реалізації такого
ПЗ.
Далі ми коротко розглянемо найбільш часто
застосовуються варіанти рішення задачі доступу мобільних користувачів до
центральній базі даних.
Використання Internet і Web
Web спочатку проектувалася як територіально
розподілена мережа, що дозволяє здійснювати доступ до різних інформаційних
ресурсів у режимі on-line. Основним недоліком даного підходу є
необхідність бути постійно підключеним до мережі. Цей недолік практично
не дозволяє застосовувати даний підхід для роботи мобільних користувачів.
Реплікація баз даних
Реплікація - це процес синхронізації даних між
декількома серверами БД. Описаний метод роботи архітектура
системи виглядає наступним чином:
Малюнок 1
Більшість сучасних серверів БД мають вбудовані
засоби для підтримки реплікації, що дозволяють обмінюватися даними між
декількома серверами. Клієнтський додаток при цьому не вимагає особливих
модифікацій. Головним недоліком такого методу є необхідність установки
та обслуговування сервера БД на машині клієнта.
Модель роботи briefcase
Briefcase модель має на увазі роботу клієнта з базою
даних без підтримки постійного з'єднання. Клієнт підключається до БД,
завантажує необхідні дані, передає зроблені ним зміни, і тут же
вимикається. У Delphi дана модель може бути реалізована з використанням
можливостей ADO або MIDAS.
При створенні програми, що реалізує модель briefcase
можна виділити кілька підзадач:
Отримання даних з центрального сервера;
Збереження даних в локальний кеш;
Завантаження даних з локального кеша;
Синхронізація даних з центральним сервером і
обробка помилок синхронізації.
Для наших прикладів як сервер БД я використовував
MS SQL сервер. На ньому була створена база даних ParamsHolder, що містить усього
одну таблицю Params з наступними полями:
Поле
Тип
Опис
ParamID
Int
Первинний ключ, identity
ParamName
Varchar (50) not null
Назва зберігається параметра
ParamValue
Varchar (50)
Значення параметра
Каркас головної форми програми наведено на малюнку. Я
не буду детально описувати каркас, при необхідності Ви можете звернутися до
комплекту 
прикладів.
Малюнок 2
Відзначимо лише, що компонент підключення до сервера
названий ParamConns, а компонент доступу до даних ParamsCS. Зосередимося на
реалізації перерахованих вище підзадач створення додатку briefcase. Всі
перераховані підзадачі реалізовані за допомогою Action-нов.
Реалізація моделі briefcase засобами ADO
Оскільки компоненти доступу до даних через ADO мають
можливість зберігати і завантажувати дані у/з файл, вони придатні для розробки
додатків briefcase.
Отримання даних з центрального сервера
Код для реалізації отримання даних з центрального
сервера, для подальшого обговорення рядка коду пронумеровані:
procedure
TForm1.act_RemoteConnectExecute (Sender: TObject);
begin
1 try
2 try
3
with ParamsCS do
4
begin
5
Close;
6
CommandType: = cmdText;
7
CommandText: = sqlText;
8
Connection: = ParamsConn;
9
Open;
10 end;
11 act_SaveLocal.Execute;
12 except
13 on E: Exception do
14 MessageDlg (Format (msgServerConnectError,
[E. Message]), mtError, [mbOk], 0);
15 end;
16
finally
17 ParamsConn.Connected: = false;
18
act_ConnectLocal.Execute;
19 end;
Завдання даного коду підключитися до центрального
серверу, отримати дані і зберегти їх в локальний кеш для подальшого
використання.
Блок try ... finally (рядки 1, 12-15) дозволяє нам поза
залежно від успішності підключення до сервера відключитися від нього і
відобразити користувачеві дані з локального кеша. Код для безпосередньо
підключення до сервера та завантаження даних міститься в рядках 2-10. Блок try
except забезпечує обробку помилок отримання даних з сервера. При
виникненні помилки користувачу відображається повідомлення про неможливість
підключення. Код, безпосередньо реалізує отримання даних, це рядки
5-9. У цих рядках ми налаштовуємо компонент класу TADODataset (ParamsCS) на
роботу з сервером і відкриваємо. Ви запитаєте: навіщо це робити кожного разу. Робити
це потрібно тому, що при відкритті локального кешу (за допомогою методу
TADODataset.LoadFromFile) датасет сам перебудовує свої властивості CommandType і
CommandText. Метод LoadFromFile викликається всередині акції act_ConnectLocal. Після
отримання з сервера ми зберігаємо вибірку на локальний кеш, викликавши відповідний
Action (рядок 11).
Збереження даних в локальний кеш
Для забезпечення можливості роботи з даними без
постійного підключення до сервера (і постійно завантаженої програми)
необхідно зберігати отримані дані і зроблені користувачем зміни.
Компоненти ADO (Спадкоємці TCustomADODataset) мають можливість зберігати
вибірку даних у файл, використовуючи метод SaveToFile. Метод має два параметри.
Перший - ім'я файлу, другий формат збереження даних. Підтримуються два формати
збереження даних:
XML
ADTG (Advanced Data Tablegram)
За замовчуванням збереження відбувається у форматі ADTG,
хоча особисто я вважаю за краще збереження у форматі XML, тому що він більш зручний для
сприйняття даних людиною.
ПРИМІТКА
Якщо ім'я файлу має розширення XML,
дані зберігаються у форматі XML, ігноруючи другий параметр методу SaveFile.
Код збереження даних в локальний кеш складається з лише
виклику методу ParamsCS.SaveFile.
Завантаження даних з локального кеша
Для завантаження даних з файлу спадкоємці
TCustomADODataSet мають метод LoadFromFile. Перед завантаженням з файлу властивість
Connection у ParamsCS необхідно встановити в nil, тому що під час завантаження
здійснюється спроба підключитися до сервера БД. Код представлений нижче:
procedure
TForm1.act_ConnectLocalExecute (Sender: TObject);
begin
ParamsCS.Connection: = nil;
ParamsCS.LoadFromFile (ExtractFilePath (Application.ExeName) + ParamFile);
end;
ПРИМІТКА
Виклик LoadFromFile автоматично змінює
тип команди датасета (св-во CommandType) на cmdFile і в властивість CommandText
зберігає ім'я файлу, звідки була проведена завантаження.
Синхронізація даних з сервером
Синхронізація включає в себе передачу зроблених
користувачем змін та отримання інформації з сервера оновлених (оновлення від всіх
користувачів) даних. Отримання даних з сервера ми вже розглянули і тут
зупинимося на проблемі передачі змін в центральну базу. Завдання передачі
змін може бути розділена на дві непосредсвтенно передачу та обробку
помилок синхронізації.
Передача змін здійснюється викликом методу
UpdateBatch. Як ми вже говорили, причиною помилок синхронізації є
одночасне редагування одного запису декількома користувачами. За
умовчанням запис на сервері відшукується ключового поля і поля, в яких
користувач зробив зміни. При цьому якщо інший користувач встиг зробити
в тих же полях цього запису зміни та внести їх до бази, запис не може бути
виявлена. Виникає помилка синхронізації. Алгоритм пошуку запису
контролюється властивістю Update Criteria об'єкту ADO RecordSet. Update Criteria
може приймати наступні значення:
AdCriteriaAllCols
Пошук за сукупністю всіх стовпців.
Найбільш «жорсткий» режим.
AdCriteriaKey
Пошук тільки по ключових полях.
Найбільш «м'який» режим. Конфлікт виникає лише при видаленні запису з бази.
AdCriteriaTimeStamp
Якщо в таблиці є поле типу TimeStamp
для синхронізації буде використано воно
AdCriteriaUpdCols
Пошук за сукупністю ключових полів і
полів, що містять зміни даних
При виявленні помилок синхронізації генерується
виняткова ситуація класу EOleError c повідомленням про неможливість зберегти
зміни. Обробка помилок синхронізації підтримується в ADO, починаючи з
версії 2.7. При цьому алгоритм вирішення конфліктів, наведений в MSDN,
Наступне:
Властивість Filter об'єкта Recordset ADO встановити
рівним adFilterConflictingRecords. При цьому будуть відображені тільки конфліктні
запису.
Викликати метод Resync того ж об'єкта з параметром
AffectRecords рівним adAffectGroup, параметр ResyncValues рівним
adResyncUnderlyingValues, при цьому будуть отримані оновлені дані про
стані конфліктних записів з сервера. Актуальні значення полів записів
рекордсета зберігаються у властивості UnderlyingValue об'єкта Field, початкові в
OriginalValue, а змінені користувачем в Value.
відобразивши користувачеві набір конфліктних записів і
значення їх полів ми даємо йому можливість відредагувати конфліктні запису і
усунути конфлікти.
Записати в БД зміни користувача можна викликавши
UpdateBatch з параметром adAffectGroup.
Обробку помилок я виніс в окремий модуль
ADOReconcileError. У ньому визначено процедуру HandleADOReconcileError,
що відповідає за підтримку обробки помилок синхронізації. Сам же код
синхронізації виглядає так:
try
ParamsConn.Connected: = true;
ParamsCS.Connection: = ParamsConn;
ParamsCS.UpdateBatch;
except
on E: EOleException do begin
HandleADOReconcileError (ParamsCS);
end else raise;
end;
act_RemoteConnect.Execute;
Скасування внесених змін
Ще однією особливістю використання ADO є
можливість користувачеві скасування зроблених ним змін. Дана можливість
реалізується методом CancelBatch. Коли Ви робите c параметром arAll (параметр по
замовчуванням) скасовуються всі зроблені зміни. Коли Ви робите з параметром
arCurrent будуть скасовані зміни, внесені в поточну запис датасета.
У наступній частині статті буде розглянута реалізації
моделі briefcase за допомогою засобів MIDAS.
Список літератури
Для підготовки даної роботи були використані
матеріали з сайту http://www.rsdn.ru/
