Современные информационные технологии. Программное обеспечение

К.т.н. Бурлаков А.А.

Хмельницький національний університет, Україна

Архітектурне рішення задачі організації доступу

до інформації в java-додатках

Більшість розроблюваного програмного забезпечення (ПЗ) залежить від інформації, яку воно отримує з різних джерел. Це можуть бути безпосередньо бази даних різних типів (реляційні, об’єктно-реляційні, об’єктні, ієрархічні, тощо), файли. Часто додатки можуть взагалі не знати про фізичні аспекти реалізації джерел інформації, бо отримують цю інформацію через інтерфейси сервісів сторонніх систем, причому ця інформація надається зазначеними сервісами в певних форматах і підлягає наступному опрацюванню.

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

В роботі пропонується розглянути ефективне архітектурне рішення задачі створення гнучкого механізму доступу до інформації, що грунтується на шаблоні DAO (Data Access Object), та показати деякі аспекти його реалізації в коді на мові java.

Припустимо, що ми розробляємо програмну систему, яка маніпулює даними деякого видавництва. Не зважаючи на те, в якій формі і з яких джерел отримана інформація, для її використання в об’єктно-орієнтованих програмах вона має бути попередньо інкапсульована в так звані «об’єкти-сутності». Для спрощення зазначимо, що в нашому ПЗ поряд з іншими «об’єктами-сутностями» предметної області існують такі «об’єкти-сутності» як книжки, автори книжок (рис.1). Саме на маніпулюванні цими сутностями ми і сконцентруємо увагу.


Рис.1 – Деякі «класи-сутності» предметної області

На рисунку 2 зображено діаграму класів, яка показує структуру паттерну DAO в рамках деякого прецедента системи. Опишемо, коротко, учасників діаграми та їх взаємозв’язок.

Рис.2 – Діаграма класів з елементами патерну DAO

Клас з ім’ям View ототожнює деякий узагальнений інтерфейс користувача в рамках прецеденту (це може бути інтерфейс написаний на JavaFX, Java Server Faces, та інших технологіях чи мовах). Він збирає дані від користувача і звертається до класу BusinessController за виконанням бізнес-логіки варіанта використання.

Клас BusinessController призначений для утворення об’кта, який очікує звернень від об’єкта типу View для проведення обчислень та поінформування останнього про їх результати (двонаправлена асоціація). Для виконання своїх обов’язків BusinessController може здійснювати маніпулювання сутностями предметної області.

Клас Entity слугує шаблоном «об’єктів-сутностей», що інкапсулюють дані з постійних хранилищ в оперативній пам’яті для зручного їх представлення в об’єктно-орієнтованих програмах. Слід наголосити, що в рамках пецедента можуть використовуватись об’єкти різних типів сутностей (наприклад типів «Автор» і «Книга»).

Призначення об’єкту класу DataAccessObject – містити методи для здійснення операції CRUD над «об’єктами-сутностями» в постійному хранилищі. Для виконання цих функцій він делегує виклики DataSource, який інкапсулює джерело даних (база даних, наприклад, RDBMS, система плоских файлів, XML-репозиторій, інша система, служба або який-небудь репозиторій LDAP). Слід зазначити, що для кожного типу сутності (Автор, Книга, тощо) в системі має утворюватись свій тип DAO-об’єкта, який створює, відшукує, змінює та видаляє конкретний тип об’єкта-сутності. Контролер бізнес-логіки має звертатися до одного екземпляра DAO-об’єкта за послугами, а той, в свою чергу, може виконувати CRUD-операції над одним чи більше єкземплярами об’єктів-сутностей.

Які переваги надає такий спосіб організації архітектури системи стосовно механізму доступу до хранилищ даних? По-перше, об’єкт типу BusinessController тепер займається лише виконанням бізнес-логіки, а обов’язки по відпрацюванню операцій CRUD над сутностями делегується об’єкту DAO. Це рішення дозволить в майбутньому робити легку заміну одних версій об’єктів DAO на інші; по-друге, сам DAO-об’єкт теж володіє певною гнучкістю, бо запити до фізичного хранилища він делегує DataSource, який теж можна динамічно замінювати.

На рис.3 представлена діаграма послідовності дій, що показує взаємодії між різними учасниками в даному шаблоні.

Рис. 3 – Діаграма послідовності для шаблона DAO

Залишаються питання по структурі самих DAO-об’єктів і механізму, що їх створює. Нас буде цікавити ситуація, коли проектується система, яка матиме змогу працювати з різними видами фізичних хранилищ даних (бази даних різних типів, файли, сервіси зовнішніх систем, тощо).

Для забезпечення цього механізму ми можемо використати можливості утворюючого шаблону проектування Abstract Factory (рис.3).

Рис.3 – Використання патерну AbstractFactory для генерації DAO-об’єктів

Наведемо реалізацію патерну DAO в коді на мові java. На рисунку 4 показано абстрактний клас, який містить реалізацію метода getDAOFactory(...) по утворенню конкретних фабрик генераторів DAO-об’єктів для різних типів фізичних хранилищ даних, та декларацію методів отримання конкретних генераторів (AuthorDAO, BookDAO, тощо), що реалізує кожна з фабрик.

Рис.4 – Абстрактний клас DAOFactory

На рисунку 5 приведено елементи реалізації фабрики DAO-об’єктів для реляційних сховищ, з якими java-програма співпрацює за технологією Java Persistence API (JPA). Кожен з конкретних DAO-об’єктів (рис. 7) наслідується від абстрактного узагальненого DAO (рис. 6).

Рис. 5. - Реалізація DAOFactory для реляційного сховища даних

Рис. 6. – Абстрактний DAO

Рис. 7. – Код конкретного DAO-генератора для підтримки роботи

з об’єктами-сутностями типу «Автор»

Кожен DAO-об’єкт є універсальним через те, що виконує звертання до фізичного джерела не безпосередньо, а делегує виклики запитів об’єктам типу DataSource (рис. 8), одну з реалізацій якого наведено на рис. 9.

Рис. 8. – Інтерфейс доступу до фізичних хранилищ даних

Рис. 9. – Інкапсуляція реляційного джерела даних

У прикладі на рисунку 10 показано використання генератора DAO і DAO. Якщо реалізація міняється від реляційного до іншого сховища, необхідно змінити тільки виклик методу getDAOFactory () в генераторі DAO для отримання іншого генератора.

Рис. 10. – Елементи коду клієнта, де показано використання патерну DAO

Таким чином, при використанні патерну DAO розробник отримує наступні переваги [1]:

- додавання прозорості. Бізнес-об'єкти можуть використовувати джерело даних, нічого не знаючи про конкретні деталі його реалізації. Доступ є прозорим, оскільки деталі реалізації приховані усередині DAO;

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

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

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

- додає додатковий рівень. Об'єкти DAO створюють додатковий рівень об'єктів між клієнтом даних і джерелом даних, який повинен бути розроблений і реалізований для використання переваг, пропонованих даними паттерном. Але за реалізовані при цьому переваги доводиться платити додатковими зусиллями при розробці.

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

Література

dataaccessobject-138824.html, вільний. – Назва з екрану. - Дата звернення: 05.12 2015.– Мова англ.

2. Б. Эккель. Философия Java. Библиотека программиста. 4 издание.– СПб. – Питер, 2009. – 559 с.

3. Г. Шилдт Java Полное руководство. 8-е изд. – М. ООО «И.Д. Вильямс». – 2012. – 1104 с.