Трирівнева Архітектура
Це виконується для розділення конкретної логіки на різні класи/пакети, замість написання всього в одному класі.
Порядок обробки запиту: Controller → Service → Repository. Після цього відповідь повертається у зворотному порядку: Repository -> Service -> Controller. Почнемо реалізацію з шару Repository.
Рівень Repository
Це найнижчий шар, де ми отримуємо оброблені дані з шару Service та зберігаємо їх у базі даних.
Ці класи позначаються анотацією @Repository, щоб бути доданими до Spring-контексту.
Main.java
1234@Repository public class RepositoryLevel { // connect DB }
Приклад використання репозиторію
Рівень сервісу
Тут відбувається основна логіка додатку. У сервісах обробляються або змінюються дані перед передачею їх до шару репозиторіїв.
Для сервісів використовується анотація @Service, яка позначає клас як service, що містить бізнес-логіку.
Main.java
1234567@Service public class ServiceLevel { public void logic() { //TODO: write business logic } }
Приклад використання сервісу
Рівень контролера
Цей шар відповідає за початкову взаємодію між клієнтом і сервером. Усі запити, що надходять від клієнта, потрапляють сюди, і він відповідає за отримання даних, наданих клієнтом.
Він обробляє вхідні HTTP-запити та повертає HTTP-відповіді. Контролери виконують роль "мосту" між клієнтом і бізнес-логікою.
На цьому рівні використовуються дві анотації для позначення класу як контролера:
-
@RestController: Оголошує клас як REST-контролер, який обробляє HTTP-запити та повертає дані у форматі JSON; -
@Controller: Оголошує клас як MVC-контролер, який обробляє запити та повертає подання (наприклад, HTML).
Main.java
12345678@Controller public class ControllerLevel { @GetMapping("/root") public String getPage() { return "template"; } }
Анотація @GetMapping визначає URL для заданого запиту. Це означає, що ми додаємо вказаний шлях /root до домену і у відповідь отримуємо відповідну сторінку.
Приклад використання контролера
Залежність Thymeleaf з відео
Ось посилання на Thymeleaf залежність у Maven репозиторії.
Але що станеться, якщо не дотримуватися цього підходу?
Технічно, нічого не станеться. Навіть якщо ви напишете всю бізнес-логіку у контролері, підключитеся до бази даних там і повернете відповідь клієнту з того ж місця, все працюватиме так само.
Однак, навряд чи ви згадаєте, що саме ви написали там через кілька тижнів, оскільки вся логіка застосунку буде зосереджена в одному місці, що є надзвичайно незручно.
Підсумок
Трирівнева архітектура забезпечує чітке розділення відповідальностей між шарами controllers, services та repositories, що робить процес розробки більш організованим та зручним для підтримки.
Кожен шар зосереджується на своєму завданні, що спрощує як робочий процес, так і керування проєктом.
Дякуємо за ваш відгук!
Запитати АІ
Запитати АІ
Запитайте про що завгодно або спробуйте одне із запропонованих запитань, щоб почати наш чат
Awesome!
Completion rate improved to 3.45Трирівнева Архітектура
Свайпніть щоб показати меню
Це виконується для розділення конкретної логіки на різні класи/пакети, замість написання всього в одному класі.
Порядок обробки запиту: Controller → Service → Repository. Після цього відповідь повертається у зворотному порядку: Repository -> Service -> Controller. Почнемо реалізацію з шару Repository.
Рівень Repository
Це найнижчий шар, де ми отримуємо оброблені дані з шару Service та зберігаємо їх у базі даних.
Ці класи позначаються анотацією @Repository, щоб бути доданими до Spring-контексту.
Main.java
1234@Repository public class RepositoryLevel { // connect DB }
Приклад використання репозиторію
Рівень сервісу
Тут відбувається основна логіка додатку. У сервісах обробляються або змінюються дані перед передачею їх до шару репозиторіїв.
Для сервісів використовується анотація @Service, яка позначає клас як service, що містить бізнес-логіку.
Main.java
1234567@Service public class ServiceLevel { public void logic() { //TODO: write business logic } }
Приклад використання сервісу
Рівень контролера
Цей шар відповідає за початкову взаємодію між клієнтом і сервером. Усі запити, що надходять від клієнта, потрапляють сюди, і він відповідає за отримання даних, наданих клієнтом.
Він обробляє вхідні HTTP-запити та повертає HTTP-відповіді. Контролери виконують роль "мосту" між клієнтом і бізнес-логікою.
На цьому рівні використовуються дві анотації для позначення класу як контролера:
-
@RestController: Оголошує клас як REST-контролер, який обробляє HTTP-запити та повертає дані у форматі JSON; -
@Controller: Оголошує клас як MVC-контролер, який обробляє запити та повертає подання (наприклад, HTML).
Main.java
12345678@Controller public class ControllerLevel { @GetMapping("/root") public String getPage() { return "template"; } }
Анотація @GetMapping визначає URL для заданого запиту. Це означає, що ми додаємо вказаний шлях /root до домену і у відповідь отримуємо відповідну сторінку.
Приклад використання контролера
Залежність Thymeleaf з відео
Ось посилання на Thymeleaf залежність у Maven репозиторії.
Але що станеться, якщо не дотримуватися цього підходу?
Технічно, нічого не станеться. Навіть якщо ви напишете всю бізнес-логіку у контролері, підключитеся до бази даних там і повернете відповідь клієнту з того ж місця, все працюватиме так само.
Однак, навряд чи ви згадаєте, що саме ви написали там через кілька тижнів, оскільки вся логіка застосунку буде зосереджена в одному місці, що є надзвичайно незручно.
Підсумок
Трирівнева архітектура забезпечує чітке розділення відповідальностей між шарами controllers, services та repositories, що робить процес розробки більш організованим та зручним для підтримки.
Кожен шар зосереджується на своєму завданні, що спрощує як робочий процес, так і керування проєктом.
Дякуємо за ваш відгук!
