Частина 2. Поговоримо трохи про архітектуру ПЗ

Цей матеріал - частина циклу " Введення в Enterprise-розробку ". Перша частина про мережу - тут . Архітектура програмного забезпечення - структура, на базі якої створюється програма, взаємодіють модулі та компоненти всієї програми. За створення гарної архітектури програмісти взялися ще дуже давно, тому не дивно, що наразі нам відомо чимало архітектурних шаблонів. Розбиратися в них потрібно: коли пишеш веб-додаток, проблема архітектури стає гострою, адже в ній компонентів та модулів більше, ніж у звичайному додатку. Архітектурний шаблон— це вже вигаданий спосіб вирішення якогось завдання з проектування програмного забезпечення. Ти вже, напевно, стикався з такими патернами проектування як фабричний метод (Factory Method), абстрактна фабрика (Abstract Factory), будівельник (Builder), прототип (Prototype), одинак ​​(Singleton) і, можливо, іншими. Вони використовуються при простому написанні коду, створенні класів та плануванні їхньої взаємодії. Архітектурні шаблони задіяні на вищому рівні абстракції - при плануванні взаємодії користувача програми із сервером, даними та іншими компонентами проекту. Давай відразу розглянемо деякі шаблони та те, як їх використовувати.

Клієнт-серверна архітектура

З назви складається враження, що з цією темою все й зрозуміло. Але давай уточнимо деякі моменти, щоб приступивши до вивчення умовного Спрингу ти точно розумів, про що йдеться. Допустимо, ти написав чат, і ви з приятелем починаєте його використовувати. Тут можливий простий варіант - ви відправляєте повідомлення один одному безпосередньо через інтернет за IP-адресаами, які ви знаєте: Спочатку може здатися, що все добре працює, поки не виникає ще один ваш друг з питанням: "А чому ви не додасте мене до свого чату?". І ось коли ти вирішуєш додати спільного друга в чат, ти стикаєшся з архітектурною проблемою: кожному користувачеві чату потрібно оновити інформацію про кількість користувачів, додати IP-адресау нового користувача. А ще під час відправлення повідомлення воно має доставлятися всім учасникам. Це найочевидніші проблеми з тих, що виникнуть. Ще купа проблем буде захована у самому коді. Щоб уникнути їх, потрібно використовувати сервер, який зберігатиме всю інформацію про користувачів, знати їх адресаи. Повідомлення потрібно буде надіслати лише на сервер. А він, своєю чергою, розішле повідомлення всім адресаатам. Коли ти вирішиш додати серверну частину до свого чату, ти почнеш будувати клієнт-серверну архітектуру.

Складові клієнт-серверної архітектури

Давай розберемося, що вона є. Клієнт-серверна архітектура — шаблон проектування, основа створення веб-додатків. Ця архітектура складається з трьох компонентів:

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

2. Сервер — місце, де знаходиться твоя веб-додаток або його серверна частина. Він володіє необхідною інформацією про користувачів або може її вимагати. Також при зверненні клієнта сервер повертає йому запитувану інформацію.

3. Мережа – все просто: забезпечує обмін інформацією між клієнтом та сервером.

Сервер може обробляти безліч запитів від різних користувачів. Тобто клієнтів може бути багато, а якщо їм потрібно обмінятися інформацією між собою, робити це доведеться через сервер. Таким чином, сервер отримує ще одну додаткову функцію – контроль трафіку. Якщо йдеться про створений нами розрахований на багато користувачів чат, весь програмний код складатиметься з двох модулів:

• клієнтського - містить графічний інтерфейс для авторизації, відправлення/отримання повідомлень;

• серверного — веб-додаток, який розміщується на сервері та приймає повідомлення від користувачів, обробляє їх, а потім надсилає адресаатам.

Коли ми хочемо подивитися корисну (або не дуже корисну) інформацію в інтернеті, ми відкриваємо браузер, у рядку пошуку вводимо запит, і у відповідь отримуємо інформацію від пошукової системи. У цьому ланцюжку браузер – це наш клієнт. Він надсилає запит з інформацією про те, що ми шукаємо серверу. Сервер обробляє запит, знаходить найбільш релевантні результати, пакує їх у зрозумілий для браузера (клієнта) формат і відправляє назад. У таких складних сервісах як пошукові системи серверів може бути багато. Наприклад, сервер авторизації, сервер пошуку інформації, сервер формування відповіді. Але клієнт про це нічого не знає: для нього сервер є єдиним. Клієнт знає тільки про точку входу, тобто адресау сервера, якому потрібно надіслати запит. Згадаймо про додаток, який ми розглядали у попередній частині— моніторинг середньої температури повітря в усіх країнах у режимі реального часу. Його архітектура буде виглядати приблизно так: Наш додаток розташовується на сервері. Скажімо, кожні п'ять секунд воно надсилає запити на сервери локальних гідрометцентрів, отримує інформацію про температуру в конкретній країні, зберігає цю інформацію. Коли клієнт звертається до нас із запитом “дивитись поточну температуру повітря у світі”, ми повертаємо останню збережену інформацію, розсортовану країнами. Таким чином наша програма одночасно і сервер (коли обробляє запити користувачів), і клієнт (коли отримує інформацію в інших серверів). Проста клієнт-серверна архітектура застосовується дуже рідко і лише для дуже простих програм. Для справді великих та складних проектів використовуються різні типи архітектур, з якими ти ще познайомишся у майбутньому. Зараз же розглянемо модель, дуже схожу на клієнт-серверну.

Трирівнева архітектура

Це архітектурний шаблон, де з'являється третій учасник — сховище даних . При використанні цього шаблону три рівні прийнято називати шарами:

1. Клієнтський шар – інтерфейс користувача. Це може бути веб-браузер, якому надсилаються HTML-сторінки, або графічна програма, написана за допомогою JavaFX. Головне, щоб за його допомогою користувач міг надсилати запити на сервер та обробляти його відповіді.

2. Шар логіки – сервер, на якому відбувається обробка запитів/відповідей. Часто його називають серверним шаром. Також тут відбуваються всі логічні операції: математичні розрахунки, операції з даними, звернення до інших сервісів або сховищ даних.

3. Шар даних – сервер баз даних: до нього звертається наш сервер. У цьому шарі зберігається вся необхідна інформація, якою користується програма під час роботи.

Таким чином, наш сервер бере на себе всі зобов'язання щодо звернення до даних, не даючи можливості користувачеві звернутися до них безпосередньо.

Переваги трирівневої архітектури

Використовуючи таку архітектуру, ми отримуємо чимало плюсів, серед яких:

1. Можливість побудувати захист від SQL-ін'єкцій - це атака на сервер, при якій передається SQL-код, і при виконанні цього коду зловмисник може вплинути на нашу базу даних.

2. Розмежування даних, до яких ми хочемо регулювати доступ користувача.

3. Можливість модифікувати дані перед надсиланням клієнту.

4. Масштабованість - можливість розширити наш додаток на кілька серверів, які будуть використовувати одну і ту ж базу даних.

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

Як часто потрібно використовувати архітектурні шаблони?

Якщо ти знайомий, скажімо, з патерном проектування , ти напевно замислювався, коли його варто використовувати. Іноді важко визначитися, що робити: створити об'єкт за допомогою оператора new або використавши фабричний метод. Але згодом розуміння приходить. З архітектурними шаблонами справи трохи інакше. Enterprise-фреймворки розраховані те що, що програміст з допомогою створює проект на основі якогось загальноприйнятого патерна. Тому перед вивченням Spring Framework тобі обов'язково потрібно розуміти, що таке клієнт-серверна архітектура, трирівнева архітектура та MVC-архітектура. Не хвилюйся: про MVC-архітектуру ми ще поговоримо. Частина 1. Що потрібно знати перед вивченням Spring та JavaEE Частина 3. Протоколи HTTP/HTTPS Частина 4. Основи Maven Частина 5. Сервлети. Пишемо просте веб-додаток Частина 6. Контейнери сервлетів Частина 7. Знайомство з патерном MVC (Model-View-Controller) Частина 8. Пишемо невелику програму на spring-boot