Action-Domain-Responder with Slim

У цій публікації я покажу, як рефакторизувати програму Slim tutorial, щоб більш точно слідувати шаблону Action-Domain-Responder.

Одна приємна річ у Slim (та більшості інших фреймворків користувальницького інтерфейсу HTTP) полягає в тому, що вони вже орієнтовані на “дії”. Тобто їх маршрутизатори не передбачають клас контролера з багатьма методами дій. Натомість вони припускають закриття дії або викличний клас однієї дії.

Отже, частина дії Action-Domain-Responder вже існує для Slim. Все, що потрібно - це витягнути сторонні біти з дій, щоб чіткіше відокремити поведінку дії від домену та поведінку відповідача.

Витяг домену

Почнемо з вилучення логіки домену. У оригінальному навчальному посібнику "Дії" безпосередньо використовують два картографа джерела даних, а також вбудовують деяку бізнес-логіку. Ми можемо створити клас сервісного рівня, який називається TicketService, і перемістити ці операції з дій у домен. Це дає нам такий клас:

Ми створюємо для нього об’єкт-контейнер у index.php так:

І тепер Action може використовувати TicketService замість безпосереднього виконання логіки домену:

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

Витяг відповіді

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

Витяг презентаційної роботи в окремий респондент, щоб побудова відповідей була повністю видалена з дії, виглядає так:

Потім ми можемо додати об’єкт TicketResponder до контейнера в index.php:

І нарешті, ми можемо звернутися до Responder, а не просто до системи шаблонів, у Action:

Тепер ми можемо перевірити роботу з формування відповідей окремо від роботи в домені.

Розподілити всі побудови відповідей в одному класі з кількома методами, особливо для простих випадків, як цей посібник, добре розпочати. Для ADR не є строго необхідним наявність одного відповідача для кожної дії. Потрібно вилучити загрози щодо формування відповіді з Акції.

Але в міру збільшення складності логіки презентації (узгодження типу вмісту? Заголовки статусів? Тощо), і оскільки залежності стають різними для кожного виду відповіді, що будується, ви хочете мати відповідача для кожної дії.

Як варіант, ви можете дотримуватися одного відповідача, але зменшити його інтерфейс до одного методу. У такому випадку ви можете виявити, що використання корисного навантаження домену (замість результатів "оголеного" домену) має деякі суттєві переваги.

Висновок

На даний момент програма Slim tutorial перетворена на ADR. Ми розділили логіку домену на TicketService, а логіку презентації - на TicketResponder. І легко зрозуміти, як кожна дія робить майже те саме:

Маршали вводять і передають його в домен
Повертає результат із Домену та передає Респонденту
Викликає відповідача, щоб він міг побудувати та повернути відповідь

Тепер для простого випадку, як цей, використання ADR (або навіть веб-MVC) може здатися надмірним. Але прості випадки швидко ускладнюються, і цей простий випадок демонструє, як можна застосовувати розділення проблем ADR, оскільки додаток на основі Slim збільшує складність.