Синхронізації і зберігання даних в мобільних частково пов'язано Настройки
Система db4o реплікації (DRS) дозволяє користувачам, такі як Індра, Boeing і EasternData легко створювати додатки, які синхронізують об'єктів двонаправленим між db4o в мобільну базу даних випадках і іншим примірником db4o сервер, Versant об'єктних баз даних (VOD) і яких-небудь загальних реляційних баз даних, таких як Oracle, MySQL і т.д.
Включення Agile програміст
об'єктно-орієнтованого реплікації DRS підхід розроблений спеціально для динамічних підприємств у мінливому й усе більш мобільних бізнес-середовищі. DRS оптимізований для легкої синхронізації розподілених примірників баз даних і часто рефакторинг програмного коду, який у минулому був важким, якщо не неможливо досягти в той же час.
Наприклад, бізнес-об'єкт "Клієнт" (містить інформацію особового рахунку) необхідно синхронізації між продавця частково пов'язано КПК та внутрішнього сервера підприємства. Батько-нащадок в класи забезпечують природне опис того, що складає об'єкт "замовник" і те, що повинні бути прийняті разом з батьківським об'єктом. Щоб домогтися повної синхронізації цього бізнес-об'єкта, забудовник просто потрібно підключити дві бази даних випадках для запиту оновленого "клієнта" об'єктів, а потім синхронізувати їх - за допомогою всього одного рядка коду:
| 01 | / / Початок реплікації сесії |
| 02 | ReplicationSession replicationSession = |
| 03 | Replication.begin (mobileDatabase, centralDatabase); |
| 05 | / / Отримати всі зміни з моменту останньої реплікації |
| 06 | ObjectSet changedCustomers = mobileDatabase.objectsChangedSinceLastReplication (Customer.class); |
| 08 | / / Перенесення змінених об'єктів |
| 09 | для (Object changedCustomer: changedCustomers) {replicationSession.replicate (changedCustomer);} |
| 10 | / / Фіксація реплікації сесії |
| 11 | replicationSession.commit (); |
У звичайних, реляційні технології, бізнес-об'єкт "клієнт" може включати в себе багато десятків реляційних таблиць, в яких все має бути на які посилається дротових, статичний код програми, що складаються з багатьох ліній, включаючи немісцевих SQL рядки, які роблять рефакторинг ще більше громіздким.
Унікальні: об'єктно-орієнтоване Синхронізація вирішення конфліктів
Однією з унікальних особливостей DRS є його база даних (а не програми) приводом вирішення конфлікту. Модель даних програми, які повинні бути єдиним джерелом для орієнтованих на дані бізнес-логіки, може бути використаний для вирішення конфліктів, а не покладатися на вторинні сховища коду програми.
Синхронізація конфлікти виникають, коли об'єкт одночасно зміна у відключених примірників баз даних з моменту їхньої останньої сесії реплікації. Після цього користувач може вибрати модель бізнес-правила, які автоматично розв'язати ці конфлікти шляхом перезапису змін, з одного боку на іншу, минаючи суперечили об'єкту, зупиняючи реплікацію, щоб уникнути пошкодження даних та / або розміщення повідомлення рутини, щоб викликати подальші дії користувача або інших бізнес-правил.
| 1 | ReplicationEventListener слухача = новий ReplicationEventListener () { |
| 2 | громадських onReplicate недійсними (ReplicationEvent подія) { |
| 3 |
якщо (event.isConflict ()) { |
| 4 | / / Перевизначення записи з копією КПК (постачальника) |
| 5 | event.overrideWith (event.stateInProviderA ()); |
Наприклад, бізнес-об'єкт "клієнт" міг зміна номера телефону в обох продавця частково форуму КПК і назад базі даних CRM офісу. Бізнес-логіка може вимагати, щоб продавець має "право власності" на клієнта і може переписати всі бек-офіс зміни, якщо тільки певних випадках застосовувати (наприклад, певні права для бек-офіс користувачів або певного виду угоди, такі як користувацькі самообслуговування угоди, які могли б бути "вище" право власності продавця). Це бізнес-логіки не повинно бути важко-проводной (як в реляційної технології реплікації) в сам додаток, але зберігатися разом з об'єктом, щоб зробити його "розумним", щоб автоматично синхронізувати себе при дотриманні всіх відповідних і останній бізнес-правил.
І гарною новиною є те, що ви отримаєте всі ці можливості синхронізації навіть в умовах обмежених ресурсів без шкоди для ефективності. З докторами можна ініціювати сеанс синхронізації формі мобільного пристрою і поговорити з реляційними сервер як перший громадянин класу!