Пару вопров к ZCE?

Мне тоже сначала не пришло, но я вышел на координатора через группу на LinkedIn и со второго раза все прислали в лучшем виде.

Типизированные Request и Response

Значит там будет сложный частный случай объекта запроса. Вопрос валидации тоже спорен. Где она должна быть? Я эту проблему поднимал в другом своем вопросе с формами. Вроде бы все склоняются, что валидация должна быть в модели и не должна дублироваться больше нигде. Значит в запрос нужно добавить метод isValid, который будет будет обращаться к модели. Таким образом мы сделаем контроллер еще более тонким, что в принципе не плохо. Такие мысли приходят в голову.

Типизированные Request и Response

В популярных фреймворках такого пока нет. В лучшем случае выделяют Request как объект. Максимум — типизированные модели шаблонов.

Типизированные Request и Response

На счет валидации я с Вами согласен. Иначе пришлось бы предусматривать интерфейс по обмену информацией о результатах валидации между объектом запроса и контроллером. Основная причина применения типизированного запроса — точно определить его структуру и явно задокументировать интерфейс.

Типизированные Request и Response

В шутке ведь всегда есть доля правда. Вот я на эту долю правды и ответил. Вы, кстати, употребляете интересное понятие «ООП-программист», то есть программист, использующий объектно-ориентированное программирование, в отличие от, например, от ФП-программиста, использующего функциональное.

Типизированные Request и Response

Да. Не должен ничего знать тот самый запрос, который является частью HTTP. Но как только он передается в action — запрос начинают воспринимать именно как объект — контейнер с данными, специфичными для текущего action. Может быть это и не совсем запрос. Можно его назвать и по другому, например ActionDataContainer

Типизированные Request и Response

Просто запрос сам по себе является сущностью. Многие фреймворки выделяют запрос как специальный объект. Его типизация просто дальнейшее развитие этой идеи. Конечно, ООП прежде всего объектная декомпозиция и управление сложностью. Вот и хочется найти баланс, извлекая пользу из применения ООП и не уходя в дебри нагромождения классов.

Инкапсуляция формой логики приложения?

Проблема в том, что форма тоже должна знать правила валидации. Хотя бы для того, чтобы рассказать об этом JS специальными атрибутами контролов или сгенерированными функциями валидации. Или нужно каким-то образом извлекать формализованные правила валидации из модели и генерировать соответствующий клиентский код.

Еще одной проблемой является отличие правил валидации формы от правил валидации модели. То есть вовсе не всегда по ответу модели можно понять, в каком контроле были неправильно введены данные. Не обязательно взаимное соответствие структуры модели и полей формы. Хотя в большинстве случаев так оно и есть.

То есть должны быть 2 валидации — в форме и модели. И вот опять дублирование функциональности — изменили правило валидации в модели, а затем во всех формах, которые используют эту модель. Хотя к этому можно относиться с пониманием — одно дело UI, а другое данные.

Подумаю над вашим предложением еще. Хорошая идея.

Инкапсуляция формой логики приложения?

Форма должна инкапсулировать в себе извлечение данных из HTTP запроса, рендеринг контролов и валидацию данных на стороне формы. В контроллере обычен такой код:

SomeForm form = new SomeForm();
if(form->wasSent())
{
 if(form->validate()
  {
   BusinessLogic.saveEntity(form->field->getValue());
   System.redirect('/confirm');
  }
}

//render page with form

Если вынести все проверки на отправку форму и валидацию в базовый класс формы, то останется всего лишь переопределить соответсвующий метод формы (onPostAndValidate). Контроллер упростится

SomeForm form = new SomeForm();
form->processRequest();
//render page with form

Нужно посмотреть, что конкретно делается — смотрите подробнее форму. Да, теряется гибкость в логике обработки формы, зато упрощаются контроллеры. А форма скорее всего приобретает ненужную ответственность за вызов обработчика данных.

В принципе я вас понял. Спасибо за ответ.

Инкапсуляция формой логики приложения?

Вопрос в том, откуда вызывать операции по управлению бизнес логикой — из формы или контроллера? Где заполнять Entity-объект из формы — в самой форме или в контроллере?

Создание глобального регистра в PHP приложении?

Да, хорошее решение, наверно, как и любая другая NoSQL база данных.

Создание глобального регистра в PHP приложении?

про файлы думал, но там возникает проблема параллельного доступа. Нужно их лочить, что может привести к задержкам.

Создание глобального регистра в PHP приложении?

Данные должны сохраняться даже после перезагрузки сервера.