22. Висновок
Нагадаємо, що ми зробили в цьому документі. Ми розглянули два рівні [DAO] з однією з двох наступних архітектур:
![]() |
![]() |
Рівень [DAO1] було реалізовано за допомогою Spring JDBC, а рівень [DAO2] — за допомогою Spring JPA. Шари [DAO1] та [DAO2] реалізовували один і той самий інтерфейс [IDAO], що дозволилонаписати єдиний тест [JUnitTestDao] для тестування обох шарів [DAO];
Зробивши це, ми опублікували інтерфейс [IDAO] у мережі Інтернет таким чином:
![]() |
- у [1], рівень [IDAO] було оприлюднено у веб-середовищі через веб-рівень [2], реалізований за допомогою Spring MVC. Саме інтерфейс [IDAO] є відкритим, і ми створили дві версії веб-сервісу залежно від того, чи реалізовано цей інтерфейс за архітектурою [DAO-JDBC] чи [DAO-JPA-JDBC];
- у [B] віддалений клієнт використовує URL, що надаються веб-сервісом і забезпечують доступ до методів рівня [IDAO-serveur]. Ми забезпечили, щоб рівень [DAO-Client] [3] реалізовував інтерфейс [IDAO-serveur] [1]. Це дозволило нам використати той самий тест [JUnitTestDao], який вже застосовувався двічі;
- у [3] рівень [DAO-client] було реалізовано за допомогою Spring RestTemplate;
Зробивши це, ми забезпечили безпечний доступ до веб-сервісу:
![]() |
- у [5] запит HTTP від клієнта проходить через рівень автентифікації, реалізований за допомогою Spring Security;
Таким чином, ми модернізували попередню архітектуру до такої:
![]() |
- у [3] клієнтський додаток сам по собі є веб-додатком, що надається веб-сервером [4]. Клієнтський додаток відображає у браузері форму [5], що дозволяє надсилати запити до URL захищеного веб-сервісу. Доступ HTTP до захищеного веб-сервісу здійснюється за допомогою прошару [jS], реалізованого на JavaScript. Ця архітектура використовує так звані міждоменні запити:
- веб-сервіс надає URL у формі [http://machine1:port1/];
- веб-додаток-клієнт завантажується з URL [http://machine2:port2/]. Якщо [http://machine2:port2/] не збігається з [http://machine1:port1/] (та сама машина, той самий порт), то клієнтський браузер заблокує виклики HTTP з рівня [DAO-client-js]. Щоб вирішити цю проблему, веб-сервіс повинен дозволити міждоменні запити;
Представлені проекти були протестовані з використанням шести наступних баз даних:
- MySQL 5 Community Edition;
- SQL Server 2014 Express;
- PostgreSQL 9.4;
- Oracle Express 11g release 2;
- IBM DB2 Express-C 10.5;
- Firebird 2.5.4;
Для кожного з цих SGBD було розроблено чотири різні рівні [DAO]:
- шар, реалізований за допомогою Spring JDBC;
- шар, реалізований за допомогою Spring JPA та провайдера JPA Hibernate;
- шар, реалізований за допомогою Spring JPA та постачальника JPA EclipseLink;
- шар, реалізований за допомогою Spring JPA та постачальника JPA OpenJPA;
Отже, було представлено набір із двадцяти чотирьох різних конфігурацій. Ми доклали значних зусиль для факторизації:
- основна частина коду написана лише один раз. Вона базується на двох конфігураційних проектах Maven:
- один налаштовує рівень JDBC;
- інший — конфігурує рівень JPA;
![]() |
![]() |
Проект конфігурації Maven для шару JDBC [1] певного SGBD дозволяє:
- імпортувати архів драйвера JDBC;
- визначити ідентифікатори доступу до використовуваної бази даних та різні команди SQL, які рівень [DAO1] надсилатиме драйверу JDBC. Хоча SQL є стандартизованим, виникли проблеми з переносимістю, головним чином через наявність у запитах імен таблиць/столбців, які виявилися забороненими ключовими словами в деяких SGBD (таблиця ROLES для DB2, стовпець PASSWORD для Firebird). Крім того, хоча зазвичай імена стовпців не чутливі до регістру (великі/малі літери), у PostgreSQL виникла проблема зі стовпцем ID первинного ключа таблиць. Він хотів, щоб вона називалася id з малими літерами;
Три проекти Maven для налаштування шару JPA, [2] та SGBD дозволяють:
- імпортувати архів реалізації JPA;
- налаштувати реалізацію JPA, що використовується для конкретного підключеного SGBD. Адже саме рівень JPA надсилає команди SQL до рівня JDBC. Щоб працювати ефективно, вона повинна знати SGBD, щоб надсилати йому команди SQL, які він розпізнає. Ці команди зможуть використовувати SQL, що є власником цього SGBD, а також його особливі характеристики (типи даних, послідовності, тригери, процедури, автоматичне генерування первинних ключів тощо);
Таким чином було створено двадцять чотири проекти (4 конфігурації × 6 SGBD) — конфігураційні проекти Maven, на яких базувалися всі інші проекти, пов’язані з експлуатацією бази даних. Оскільки у наведених вище схемах шари [DAO1] та [DAO2] мають однаковий інтерфейс, 24 конфігурації обох вищезазначених архітектур було протестовано за допомогою єдиного тестового класу [JUnitTestDao]. Після перевірки цих архітектур труднощів більше не виникало:
- проект Maven з публікації бази даних у мережі базується на цих двох архітектурах. Отже, тут також існує 24 можливі конфігурації;
- проект Maven із забезпечення безпеки доступу до веб-сервісу базується на попередньому проекті і також має 24 можливі конфігурації;
- нарешті, проект Maven, що дозволяє здійснювати міждоменні запити до захищеного веб-сервісу, базується на попередньому проекті і також має 24 можливі конфігурації;
Хоча цей документ не охоплює всіх можливостей мови Java та всіх сфер її застосування, його можна використовувати як навчальний посібник з мови. Читач, який засвоїв матеріал цього курсу, досягне рівня «просунутого Java» як у використанні мови, так і у використанні фреймворку Spring. Після цього він зможе продовжити своє навчання Java за допомогою таких посібників:
- [Spring MVC et Thymeleaf par l'exemple] [http://tahe.developpez.com/java/springmvc-thymeleaf], що продовжує вивчення екосистеми Spring, представляючи її напрямок «веб-програмування MVC». У ньому використовується база даних, складніша за ту, що розглядається тут;
- [Tutoriel AngularJS / Spring MVC] [http://tahe.developpez.com/angularjs-spring4], що демонструє веб-архітектуру «клієнт/сервер», де клієнт реалізовано за допомогою фреймворку [AngularJS], а сервер — за допомогою [Spring MVC];
- [Introduction à Java EE] [http://tahe.developpez.com/java/javaee], що відходить від екосистеми Spring на користь веб-архітектури, заснованої на JSF (Java Server Faces) та EJB (Enterprise Java Bean);
- [Introduction à la programmation des tablettes Android] [http://tahe.developpez.com/android/exemples-intellij-aa], що описує архітектуру «клієнт-сервер», де клієнтом є планшет на базі Android, запрограмований на Java, а сервером — веб-сервіс, реалізований за допомогою Spring MVC;






