21. Висновок

Нагадаємо, що було викладено в цьому документі:

• основи веб-програмування на Java з використанням сервлетів та сторінок JSP
• вступ до архітектури MVC
• вступ до трирівневої архітектури
• вступ до Spring IoC
• приклади для ілюстрації цих питань

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

Для простих додатків цієї архітектури цілком достатньо. Коли ви напишете кілька додатків такого типу, ви помітите, що сервлети двох різних додатків:

1. мають однаковий механізм визначення того, який метод [doAction] потрібно виконати для обробки дії, запитуваної користувачем
2. фактично відрізняються лише змістом цих методів [doAction]

Тоді виникає велика спокуса:

• винести обробку (1) в загальний сервлет, який не знає, який додаток його використовує
• делегувати обробку (2) зовнішнім класам, оскільки загальний сервлет не знає, у якому додатку він використовується
• встановити зв’язок між дією, яку вимагає користувач, та класом, що має її обробити, за допомогою конфігураційного файлу

З’явилися інструменти, які часто називають «фреймворками», щоб надати розробникам зазначені вище можливості. Найстарішим і, ймовірно, найвідомішим із них є Struts (http://struts.apache.org/). Jakarta Struts — це проєкт Apache Software Foundation (www.apache.org). Цей фреймворк описано на сайті (http://tahe.developpez.com/java/struts/).

З’явився нещодавно фреймворк Spring (http://www.springframework.org/), який пропонує можливості, аналогічні до тих, що має Struts. Насправді це його модуль Spring MVC. Його використання описано в кількох статтях (http://tahe.developpez.com/java/springmvc-part1/).

Spring не обмежується лише концепцією MVC рівня [web] трирівневої архітектури. Він корисний навіть у додатках, що не належать до веб-сфери.

Таким чином, ми завершили наш курс, реалізувавши архітектуру MVC у трирівневій архітектурі [web, metier, dao] на прикладі простого управління списком осіб.

У версії 1 додатка список осіб зберігався в пам’яті й зникав після закриття веб-додатка. В інших версіях список осіб зберігається в таблиці бази даних. Ми використовували чотири різні SGBD: Firebird, Postgres, MySQL та SQL Server Express.

Завдяки Spring IoC шар [web] з версії 1 вдалося повністю зберегти в наступних версіях. Таким чином, ми продемонстрували, що можна будувати архітектури ntier із незалежними шарами.

У версіях, що використовують базу даних, ми продемонстрували внесок Spring у побудову шарів [dao] та [service]. Завдяки інтеграції Spring із iBATIS нам вдалося створити чотири версії, які відрізняються лише своїми конфігураційними файлами. Один і той самий клас [DaoImplCommon] використовувався для реалізації шару [dao] у всіх чотирьох версіях. Щоб вирішити проблему, характерну для SGBD Firebird, нам довелося створити похідний клас, але не змінювати його.

Нарешті, ми продемонстрували, як Spring дозволяє нам керувати транзакціями декларативним способом на рівні шару [service].

Рекомендуємо читачам ознайомитися з усіма можливостями, які пропонує цей продукт.