Action-Domain-Responder — доопрацювання MVC під завдання веба

Мета

Розділити взаємодії користувальницького інтерфейсу між веб-клієнтом і веб-додатком на три чітко визначені ролі.

ADR

Передумови

Термін MVC відчуває деякий семантичне розмиття свого первісного значення, особливо в контексті веба (див. відео Стефана Прибша для більш детального розгляду питання). Як засоби усунення цього розмиття пропоную вашій увазі опис патерну Action-Domain-Responder, що є доопрацюванням концепції MVC під потреби вирішення специфічних для веба завдань.

Я вважаю, що ADR значно краще відповідає тому, що насправді ми реалізуємо в процесі веб-розробки з дня у день. Наприклад, на створення цього патерну мене частково надихнуло те, як ми вирішуємо проблеми роутінга і диспетчеризації, адже в загальному випадку при роутинге і диспетчеризації ми звертаємося до класу контролера per se, а до якогось конкретного методу дії в цьому класі контролера.

Ще однією вскрывшейся проблемою є той факт, що часто ми розглядаємо Уявлення (View) як шаблон (template), хоча в контексті інтернету, ймовірно, більш доречно було б говорити про те, що Поданням є HTTP-відповідь. Виходячи з вищесказаного, я вважаю, що ADR здатний надати краще, ніж MVC, поділ концепцій для веб-додатків.

Компоненти

Дія (Action) — це логіка, яка пов'язує Домен (Domain) Відповідач (Responder). Воно використовує дані вводу (input) для взаємодії з Доменом і передає висновок Домену Відповідачу.

Домен (Domain) містить в собі логіку для управління сесією, додатком і даними оточення, зміни стану і управління даними в разі необхідності.

Відповідач (Responder) — це логіка, необхідна для створення HTTP-відповіді або опису відповіді. Він оперує основним контентом (body content), шаблонами і уявленнями, заголовками, cookies, кодами статусів і іншим.

Взаємодії

  1. Веб-обробник отримує запит від клієнта і передає його Дії.
  2. Дія взаємодіє з Доменом.
  3. Дія передає дані Відповідачу (ці дані можуть включати в себе результати взаємодії з Доменом, дані з клієнтського запиту і т. д.)
  4. Відповідач генерує відповідь, використовуючи дані, отримані від Дії.
  5. Веб-обробник відсилає відповідь клієнту.

Порівняння з MVC (Model-View-Controller)

Найпопулярніший патерн, що описує взаємодії в рамках веба — Модель-Представлення-Контролер (Model-View-Controller). Є Action-Domain-Responder насправді всього лише переодягненим Model-View-Controller? Можна зауважити, що елементи ADR знаходять своє достатньо чітке відображення в елементах MVC:

Model <--> Domain
View <--> Responder
Controller <--> Action

Два патерну виглядають дуже схоже. У чому ж відмінності?

У загальному і цілому, есе Фаулера "Архітектури GUI" [переклад тут] ми можемо побачити, що «у вас не просто одне подання та один контролер, ви змушені створювати окрему пару представлення-контролер для кожного блоку на сторінці кожного елемента управління і сторінки в цілому». Це основний елемент семантичного розмиття, що виникає при застосуванні MVC у веб-додатках.

І давайте більш детально порівняти окремі компоненти MVC і ADR.

Модель Домен
Я не бачу в них радикальних відмінностей, за винятком того, що в ADR Відповідач не взаємодіє з Доменом-яким істотним чином. Відповідач може використовувати об'єкти Домену як сутності і колекції, але тільки з метою відображення; Відповідач не модифікує Домен і не відправляє йому яку-б то не було інформацію, як це передбачено в рамках MVC.

Контролер Дія
У загальному випадку, більшість класів Контролера в системі, побудованій за принципами MVC, містять у собі декілька методів, кожен з яких відповідає якійсь окремій дії. Оскільки всі ці методи мешкають в одному Контролері, до нього також додається додаткова обгортковий» логіка для роботи з кожним із цих методів, наприклад, хуки, що спрацьовують безпосередньо перед або після самої дії. Значне виняток з цього правила становлять микрофреймворки, в яких кожен Контролер представляє з себе окрему замикання або викликається об'єкт, що більше відповідає саме Дії (напр. Slim).

У рамках же ADR Дії бачаться як окремі класи або замикання. Іншими словами, кожне Дія повинно бути винесено у свій окремий клас або замикання.

Дія взаємодіє з Доменом за тим же принципами, за якими Контролер взаємодіє з Моделлю, але не взаємодіє з Поданням або системою шаблонів. Дія просто передає Відповідачу дані і надає тому самостійно ними розпоряджатися.

Подання Відповідач
В системі MVC метод Контролера зазвичай генерує тіло відповіді з допомогою Подання (наприклад, через Шаблонизатор (Template View) або Двухшаговую Шаблонизацию (Two Step View)). Потім Контролер інтегрує згенероване тіло відповіді сам відповідь. Метод Контролера, що є дією, безпосередньо керує відповіддю для виставлення необхідних заголовків.

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

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

Зауважимо, що Відповідач може включати в себе Шаблонизатор, Двухшаговую Шаблонизацию, Перетворювач (Transform View) або будь-яку іншу систему уявлень. Також зауважимо, що узагальнений (generic) Відповідач може використовуватися більш ніж одним Дією. Головне — що Дія залишає всю роботу над заголовками і контентом Відповідачу, а що не потрібно створювати свій Відповідач під кожне окреме Подання.

Порівняння з іншими патернами

Існують і інші патерни, які розглядаються в якості доопрацювання, заміни або доповнення концепції MVC. Ви можете ознайомитися з цим оглядом патернів від Дерека Гріра.

EBI (Entity-Boundary-Interactor)
У терміна EBI існує кілька синонімів: порти і адаптери, гексагональна архітектура, ECB (Entity-Control-Boundary). Він описаний як частину "Чистої архітектури" Роберта Мартіна.

EBI є частковою альтернативою MVC, при якій основні елементи та поведінки, що представляються об'єктами Интеракторов (Interactor) Сутностей (Entity), відокремлені від вхідних та вихідних даних з допомогою Обмежувачів (Boundary). Головним наслідком такого підходу є чітке розмежування самого додатка і тонкощів механізмів введення і виведення, так що ключові поведінки ніколи не залежать від якої-небудь приватної системи отримання запиту або відправлення відповіді.

Зізнаюся, я не дуже добре знайомий з концепцією EBI, так що цей опис може бути не зовсім коректним в цілому або частково. Після своїх неповних досліджень в цій області, я прийшов до висновку, що архітектура EBI, ймовірно, краще описує взаємодії усередині додатку, ніж MVC. Якщо наведене вище вірно, то ADR досить добре лягає на структуру EBI:

  • ADR'івські Дія Відповідач можуть служити в якості веб-специфічного Обмежувача
  • ADR'івський Домен може служити аналогом Интерактора, інкапсулюючи або іншим чином приховуючи елементи EBI'йных Сутностей від ADR'івського Дії
Альтернативно, в рамках термінології портів і адаптерів або гексагональної архітектури, більш розумним може бути розгляд Дії «порту», через який EBI'йный Обмежувач викликається (invoke) як частина ADR'ного Домену. Нарешті, Відповідач можна розглядати як «адаптер», через який додаток повертає клієнту.

Тим не менш, ADR не здається прямою заміною EBI. Скоріше, два підходи доповнюють один одного.

DCI (Data-Context-Interaction)
DCI описується як доповнення MVC, а не заміна. Думаю, буде справедливо назвати його в тій же мірі доповненням ADR.

MVP (Model-View-Presenter)
MVP був відправлений у відставку патернами Керуючий Контролер (Supervising Controller) і Пасивне Подання (Passive View). На перший погляд, він виглядає дуже схожим на ADR, особливо тим, що Пасивне Подання Модель не мають ніяких залежностей один від одного. З тексту Фаулера:
Керуючий Контролер використовує контролер для того, щоб обробляти дані введення, так і для того, щоб керувати поданням, дозволяючи організувати більш складну логіку відображення…

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

  • Модель Домен досить сильно схожі один на одного, як і у випадку з MVC.
  • Пасивне Подання в повній мірі не відповідає ні Дії ні Відповідачу; скоріше, воно може бути розглянуто як відповідь, який повертається клієнтові.
  • Керуючий Контролер нагадує Відповідач в плані «управління уявленням, що дозволяє домагатися більш складної логіки відображення». З іншого боку, Відповідач не взаємодіє з Доменом та не отримує вхідні дані від клієнта, так що, схоже, він не дуже підходить на роль Керуючого Контролера.
  • В якості альтернативи, Керуючий Контролер можна було б представити як Дія, а Дія не відповідає за керування поданнями (тобто відповіддю).
Загалом, близько, але не те ж саме.

MVVM (Model-View-ViewModel)
MVVM тільки частково схожий з ADR. Модель MVVM є практично тим же самим, що і Модель MVC і Домен ADR. Аналогічно, Подання MVVM дуже схоже на Подання MVC і Відповідач ADR.

Проте ж Модель Представлення (ViewModel) не схожа ні на Контролер MVC, ні на Дія ADR. Оскільки ADR є доопрацюванням MVC, розумно припустити, що порівняння MVVM з MVC буде аналогічно порівнянні з ADR.

Для розгорнутого опису цих відмінностей раджу вам ознайомитись зі статтями Джоеля Вензелі, Автара Сінг Сохи, Рейчел Аппель і Нираджа Бхатта.

(У мене відбулася цікава email-дискусія, в рамках якої мені пояснили, що MVVM дуже схожий на MVC, до якого додали Модель Представлення для взаємодій між Поданням Моделлю. Якщо це насправді так, то Модель Представлення може використовуватися в ADR з тим же успіхом, що і в MVC).

PAC (Presentation-Abstraction-Control)
З Вікіпедії:
PAC являє собою ієрархічну структуру агентів, кожен з яких є тріадою з уявлення, абстракції і керуючої частини. Агенти (тріади) комунікують між собою тільки через керуючу частину кожного з них. Ще одна відмінність від MVC полягає в тому, що в кожній тріаді подання і абстракція (модель в термінах MVC) є абсолютно ізольованими. Такий підхід дозволяє обробляти моделі та подання паралельно в різних потоках, що залишає в користувача враження дуже швидкого старту, оскільки інтерфейс (подання) може бути відображений ще до того, як абстракції будуть повністю ініціалізується.
Не дуже схоже на ADR.

RMR (Resource-Method-Representation)
Я не чув про RMR, поки ircmaxell не вказав на нього на Реддите.

ADR і RMR дуже схожі один на одного, і їх елементи відповідають один одному досить точно.

Resource <--> Domain
Method <--> Action
Representation <--> Responder

Однак деякі нюанси RMR змушують мене залишитися при думці, що ці два підходи все-таки відрізняються один від одного. Наприклад:
Таким чином, в рамках об'єктно-орієнтованої мови ми можемо розглядати http-ресурси (Resource) як об'єкти з приватними властивості і певним набором публічних методів (Method), кожен з яких відповідає стандартним методом HTTP. У термінах MVC ресурс може бути представлений як модель з невеликою частинкою контролера всередині.
Особисто мені це здається просто занадто великим змішуванням концепцій. Я волію бачити більш ясне відділення моделей від дій, що чиняться над додатком.

Подання (Representation) дуже схоже на Виставу в MVC, ми віддаємо йому об'єкт ресурсу і даємо команду сериализации його в необхідний формат виводу.
Очевидно, це невірно для цілого ряду HTTP-відповідей, таких, наприклад, як «Not Found». Таку відповідь, безумовно, не є поданням запитаного ресурсу.

У загальному і цілому, ймовірно, ADR можна розглядати як доповненої і розширеної варіації RMR, в якій Ресурси і дії, які можуть бути над ними здійснені, чітко розділені на Домени Дії, де Подання (тобто генерація відповіді) управляється Відповідачем.

Models-Operations-Views-Events (MOVE)
оригінального сайту:

Моделі (Models) інкапсулюють в собі все, що ваш додаток знає.
Операції (Операцій) інкапсулюють все, що ваш додаток робить.
Вистави (Views) є сполучною ланкою між вашою програмою і користувачем.
Події (Events) використовуються, щоб безпечно з'єднати всі ці елементи.
Це дуже цікавий патерн сам по собі. Ідея Моделей Операцій здається вельми придатною в рамках «Domain-Driven Design»-підходу.

Тим не менше, я не думаю, що MOVE схожий на ADR, особливо ось у цьому моменті:

Події — це саме те, що дає MOVE (і MVC) інверсію управління (inversion of control), необхідну, щоб моделі мали можливість оновлювати подання без отримання інформації про те, яке саме уявлення вони оновлюють.
В ADR, Домен Відповідач «оновлюють один одного». Робота Домену завершена, а результат переданий Відповідачу для подальшого відображення клієнту.

Separated Presentation
Можна знайти кілька вказівок на ADR, особливо на Відповідач, Роздільних Уявленнях. Стаття сама по собі заслуговує на прочитання, однак Окремі Подання швидше є мета-паттерном, що описує загальні підходи до відокремлення даних від їх подання, а не конкретні шляхи досягнення цього поділу.

Порівняння MVC і ADR на прикладах

Вихідна точка у MVC
У MVC структура директорій для банальної блогової системи може виглядати приблизно так. Зауважте, що index та read надають в якості альтернативи висновок в JSON, а шаблон коментарів є «частковим» (partial) і теж дає можливість виведення JSON в якості альтернативи.

controllers/
BlogController.php # index(), create(), read(), update(), delete()
models/
BlogModel.php
views/
blog/
index.html.php
index.json.php
create.html.php
read.html.php
read.json.php
update.html.php
delete.html.php
_comments.html.php
_comments.json.php

А ось інший тип структури директорій для MVC:

Blog/
BlogController.php # index(), create(), read(), update(), delete()
BlogModel.php
views/
index.html.php
index.json.php
create.html.php
read.html.php
read.json.php
update.html.php
delete.html.php
_comments.html.php
_comments.json.php

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

<?php
use Framework\Controller;

class BlogController extends Controller
{
public function create()
{
// this is a POST request?
if ($this->request->isPost()) {

// retain incoming data
$data = $this->request->getPost('blog');

// create a blog post instance
$blog = $this->blog_model->newInstance($data);

// is the new instance valid?
if ($blog->isValid()) {
// yes, save and redirect to editing
$blog->save();
$this->response->redirect('/blog/edit/{$blog->id}');
return;
} else {
// no show the "create" form with the blog instance
$this->response->setContent($this- > view- > render(
'create.html.php',
array('blog' => $blog),
));
return;
}
} else {
// not a POST request, show the "create" form with defaults
$this->response->setContent($this- > view- > render(
'create.html.php',
array('blog' => $this->blog_model->getDefault())
));
}
}

public function index()
{
// ...
}

public function read($id)
{
// ...
}

public function update($id)
{
// ...
}

public function delete($id)
{
// ...
}
}
?>

Логіка методу create() може бути деяким чином скорочена за рахунок винесення більшої частини взаємодій з моделлю на Сервісний Рівень (Service Layer), але суть залишиться колишньою — саме Контролер зазвичай відповідає за заголовки відповіді і контент.

Поглянемо на ADR
Для порівняння, структура папок при ADR може бути організована таким чином. Звернемо увагу, що у кожного Дії є відповідний йому Відповідач.

Blog/
Action/
BlogIndexAction.php
BlogCreateAction.php
BlogReadAction.php
BlogUpdateAction.php
BlogDeleteAction.php
Domain/
# Model, Gateway, Mapper, Entity, Collection, Service, etc.
Responder/
BlogIndexResponder.php
BlogCreateResponder.php
BlogReadResponder.php
BlogUpdateResponder.php
BlogDeleteResponder.php
html/
index.html.php
create.html.php
read.html.php
update.html.php
delete.html.php
_comments.html.php
json/
index.json.php
read.json.php
_comments.json.php

Пара з Дії Відповідача, відповідних розглянутого вище методу Контролера create(), могла б виглядати так:

<?php
use Framework\Action;

class BlogCreateAction extends Action
{
public function __invoke()
{
// this is a POST request?
if ($this->request->isPost()) {

// yes, retain incoming data
$data = $this->request->getPost('blog');

// create a blog post instance
$blog = $this->blog_model->newInstance($data);

// is the new instance valid?
if ($blog->isValid()) {
$blog->save();
}

} else {
// not a POST request, use default values
$blog = $this->blog_model->getDefault();
}

// set data into the response
$this->responder->setData(array('blog' => $blog));
$this->responder->__invoke();
}
}
?>


<?php
use Framework\Responder;

class BlogCreateResponder extends Responder
{
// $this->response is the actual response object, or a response descriptor
// $this- > view is a view or template system
public function __invoke()
{
// there is an ID on the blog instance?
if ($this->data->blog->id) {
// yes, which means it was saved already.
// redirect to editing.
$this->response->setRedirect('/blog/edit/{$blog->id}');
} else {
// no, which means it has not yet been saved.
// show the creation form with the current response data.
$this->response->setContent($this- > view- > render(
'create.html.php',
$this->data
));
}
}
}
?>

Знову ж таки, можна знайти можливості для рефакторінгу і в цьому коді, особливо в частині роботи з Доменом. Головне — що Дія не виконує ніякої роботи Відповідача; вся необхідна робота виконується безпосередньо логікою самого Відповідача.

Ви можете вивчити розширений приклад коду на ADR тут.

Коментарі

Не розглянуті запити
Я отримав досить багато критики з-за того, що не включив у патерн елемент, відповідний «HTTP запитом». Рання версія цієї публікації містила у собі такий елемент і була названа «Request-Action-Domain-Response». Тим не менш, при подальшому вивченні MVC і схожих архітектурних патернів я помітив, що ні один з них не визначає елемент вводу. Щоб не вибиватися із загального ряду, ADR теж не розглядає цей елемент.

Не розглянуто Фронт-Контролер
Патерн створений для поліпшення підходу Модель-Додаток-Контролер, а не веб-додатків взагалі. Таким чином, в ньому умисно не розглядаються деякі елементи, властиві багатьом веб-додатків, і зокрема це відноситься до Фронт-Контролеру.

ADR не описує елемент роутінга або диспетчеризації, і так само він не описує, як з диспетчеризацією пов'язані Дія Відповідач. Роутинг і диспетчеризація найчастіше є зоною відповідальності Фронт-Контролера, і існує багато способів налагодити взаємодію між Дією, Відповідачем Фронт-Контролером:

  • Дія може безпосередньо викликати Відповідач, повертає відповідь на запит;
  • Відповідач і відповідь можуть бути доступні фронт-контролеру, що викликає їх безпосередньо;
  • Дія може повертати Відповідач, який потім викликається і повертає відповідь, який викликається і відсилає сам себе;
  • і так далі.
Патерн ADR не описує ніяких елементів попередньої фільтрації або валідації запиту, так як вони можуть бути частиною Фронт-Контролера. Зверніть увагу, що, в залежності від логіки попередньої фільтрації та валідації запиту, Дія може викликати Відповідач, або воно може повернути свій власний відповідь, або викликати якесь додаткове Дія в результаті роботи своєї логіки і так далі. Аналогічним чином, викликане Дія може мати свій власний набір перевірок, що приводить до виклику Відповідача без взаємодії з Доменом. Причинами таких «вкорочених» ланцюжків виклику можуть бути:

  • Неузгодженість HTTP методів. Якщо роутинговая система не виявить відповідності між використовуваним HTTP-методом і замовленим Дією, Фронт-Контролер може повернути відповідь з помилкою замість перенаправлення запиту до Дії.
  • Аутентифікація. Наявність або відсутність прав доступу у клієнта (та їх валідність) може впливати на необхідність виклику Дії або взаємодії з Доменом під час цього Дії.
  • Авторизація. Система контролю доступу може відхилити клієнтський запит певного Дії, або призвести до того, що Дія буде виконано без взаємодії з Доменом і, можливо, самостійно поверне відповідь.
  • Невідповідність вмісту. Фронт-Контролер, Дія або інші беруть участь в обробці запиту елементи можуть перевіряти Accept-заголовки клієнтського запиту. Невідповідність цих заголовків може примусово виключити Дія або Домен з обробки запиту та/або привести до раннього висновку відповіді.
  • Валідація контенту. Якщо дані вхідного запиту з якоїсь причини не вважаються валідними, Дія може відмовитися від взаємодії з Доменом і безпосередньо викликати Відповідач для передачі повідомлення про помилку.
Альтернативні формулювання
ADR може бути названий варіацією на тему Контролера Подання в паттерні Модель-Представлення-Контролер, а не самостійним паттерном.

Тоді вийде, що Дія представляє із себе варіацію, схожу Контролером Сторінки (Page Controller), і в такому контексті її більш точною назвою може бути Контролер Дії (Action Controller). В цьому випадку воно буде відповідати Контролеру з MVC. (Більше того, формальний опис Контролера Сторінки " свідчить, що він являє собою «сторінку або дія»).

Аналогічно можна розглядати Відповідач як варіацію, схожу Шаблонизатором (Template View) або Перетворювачем (Transform View), і тоді розумніше було б назвати його Поданням Відповіді (Response View). Таким чином, Відповідач цілком вписується в елемент Подання з MVC.

Незважаючи на все вищесказане, я вважаю, що ці альтернативні формулювання не так гарні і точні, як опис підходу в рамках окремого патерну ADR. Здебільшого — через внутрішніх взаємодій між Моделлю Поданням: MVC Подання оновлює Модель, ADR Відповідач не оновлює Домен.

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

Крім того, можливо, Дії слід передавати Відповідачу не дані, отримані від Домену, ,Подання Моделі (Presentation Model). Але в такому разі, можливо, саме Домен, що викликається Дією, повинен повертати Представлення Моделі, инкапсулирующее стан програми.

У будь-якому випадку, ADR пропонується як доробка MVC. Виходячи з цього, ми можемо сказати про Домені ADR все те ж саме, що можна сказати про Моделі MVC.

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

Хоча на мою думку патерн сам по собі виражає ідею про те, що кожне Дія має виконувати лише одну функцію, і це однозначно випливає з порівнянь Контролера Дії і патернів ADR і RMR, я ще раз уточню, вже у більш явному вигляді: сенс полягає в тому, що кожне Дія має виконувати одне і тільки одне дія у відповідь на будь-вхідний запит.

Заміна, а не доопрацювання MVC
Нейт Эйбель заперечує, що ADR слід вважати заміною MVC, використовуваної для серверних додатків:

Скажу, що чим більше я дізнаюся про паттерне MVC, тим менше він мені бачиться підходящим для серверної частини веб-додатків. <...> Думаю, головний прорив твоєї ідеї ADR — це відв'язування від того, що здається мені поганий абстракцією. Я б радив тобі уникати опису ADR в термінах MVC за винятком тих випадків, де це абсолютно необхідно.
Повний коментар.

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

Стефан Хохдерфер відповів на мою ідею в цьому пості; надалі дискусія продовжилася тут і на реддите.

Джон Лейтон писав про Сфокусований Контролер (Focused Controller), який дуже схожий на Дію з ADR, тут.

Наступний пост, що порівнює Подання Відповідач, перебуває тут, а коментарі до нього на реддите — тут і тут.

Акіхіто Коритама пропонує свої зауваження тут.

Переваги та недоліки

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

Одним комплексним недоліком є те, що нам доведеться мати справу з великою кількістю класів у додатку. Свій власний клас отримає не тільки кожне Дія, але ще і кожен Відповідач.

Але цей недолік, ймовірно, не так жахливий в довгостроковій перспективі. Необхідність створення окремих класів може призвести до більш ясною і менш глибокої ієрархії успадкування. Поділ Дії Відповідача сприяє кращій тестируемости. В різних системах ці особливості можуть проявитися по-різному. Хтось помітив, що обробляти «багато класів» у різних редакторах коду і IDE зручніше, ніж «менше класів, але не більше методів», оскільки огляд класу зазвичай простіше, ніж огляд методу.

Подяку

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

  • Matthew Weier O Phinney
  • Hari KT
  • Stephan Hochdörfer
  • Adam Culp
  • Dan Horrigan
  • Josh Lockhart
  • Beau Simensen

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.