Олег Красавин: это все авто генерация. Меня окончательно задолбали активрекорды, поэтому выгрызаю время на симфони. Еще не успел детально разобраться. Спасибо.
AlikDex: нет почему ? Хелпер никуда не делся. Просто он получает очередную абстракцию. Тоесть к примеру есть метод getAmountString(), который будет возвращать скажем: Currency::formatString($product->getPrice())
AlikDex: нет number_format никогда не целесообразней использовать в голом виде. Всегда нужны обертки. В этом варианте, нужно прокидывать классы во вьюшки и организовывать статический доступ. Это не хорошо.
index0h: Извиняюсь, не много запутался с реквестами. Возможно мы друг друга не понимаем.
Я попробую показать на примере laravel5, так как я не могу выходить за более-менее стандартные его рамки.
К примеру у меня есть экшин, который принимает объект реквеста $request:
public function index(TestRequest $request)
{
}
Я не попаду в этот экшин, пока не удовлетворю валидацию реквеста и права на доступ. Я находил пример реализации некого метода sanitize (www.easylaravelbook.com/blog/2015/03/31/sanitizing..., такой подход рекомендуют для того, чтобы в контроллер уже пришли четкие данные.
Возможно это отличается от работы в симфони, но это более очевидно для сообщества laravel (кстате руководством нашей команды он был выбран, только из-за популярности).
Соответственно на основе текущей информации мое утверждение следующее:
- Я делаю запрос на сервер, к примеру отправляю форму с данными.
- Эти данные попадают в объект TestRequest $request
- Внутри TestRequest $request я осуществляю валидацию данных и привожу их к нужному мне формату. Это может быть принудительное указание типа, trim и тп.
- Когда данные доходят до экшина, я получаю массив k-v $request->all();
- Далее для сохранения целостности api этот массив перегоняем в DTO TestDTO и далее уже тащим по сервисам.
index0h: так если реквест не должен ничего обрабатывать это нужно делать контроллеру, а это лишний код в нем. Да и было бы не плохо в контроллере получить уже подготовленные данные, которым можно доверять. Возможно вы меня не поняли, но на примере ларавеля - реквест это спец. файл как раз для обработки входящих данных.
Относительно контроллера я имею ввиду, что из объекта реквест он получает уже проверенные и приобразованные данные, которые готовы к работе дальше.
Почему кий-велью это плохая практика ? Из-за отсутствия целостности апи ? Что скажете про коллекции ?
Сервисы я абстрактно, как классы доменной модели. Там могут быть разные хелперы, обработчики и тп.
По поводу исключений, может я не так выразился, но в любом случае нужно пользователю красиво показать ошибку. Даже если эта ошибка самой логики или банально упал сервер бд или внешний ресурс.
К теме видов - $errors это ларавелевский объект, который содержит информацию об ошибках. Ларавель сам его прикидывает во вьюшки. Поэтому придётся работать с ним.
index0h: не совсем понял про транзакции. Просто если контроллер дергает 2 или 3 сервиса или сервис регистрирует события, то хорошо было бы все это провернуть в транзакциях. Соответственно отсюда и идея все это дело завернуть.
Соответственно вывод:
Request - занимается строго чисткой данных и приводит их к нужному типу и формату. Не делает обращений в базу (возможно за редкими исключениями).
Controller - получает уже подготовленные данные, которые готовы для дальнейшей работы. Может вызывать сервисы и репозитории. Обрабатывает исключения и формирует ответ от сервера.
Service - принимает данные в массиве, через сеттеры или через DTO. Осуществляет логику возвращая результат. В процессе бросает исключения, которые являются своего рода валидацией данных, которые препятствуют выполнению.
View - принимает объект $errors для обработки ошибок и отображает представление.
------------------------
Поправьте, если не правильно сделал выводы.
Станислав Почепко: Спасибо. Смотрите я про доку в курсе, код не нужен. Меня интересует сугубо теоретическая правильность. Тоесть с точки зрения ООП на сколько это правильно.
Станислав Почепко: я понял, но мне кажется валидация в контроллере это как-то из ряда идея попахивающая идиотизмом. Ну тоесть за какие заслуги мы контроллеру даем лишнюю ответственность, он и так много чего делает, например сервисы вызывает, передает данные, ответ от сервера возвращает, еще исключения обрабатывает, куда ему еще валидация. Про ошибки я имел ввиду уже после реквеста, тоесть реквест прошел все хорошо, но сервис плюнул исключение, можно это дело подмешать во вьюшку ?
Станислав Почепко: тут кстате спорно, так-как не всегда нужно перенаправление. В случае с аякс например. У меня вопрос, можно ли как-то из контроллера модифицировать объект ошибок, который попадает в виды через $errors
index0h: да это понятно. Не везде есть реквест, например в консольных командах. Я образно. Я беру данные из репозитория и работаю с ними в сервисе. По поводу анти практик, ларавель мальца круче Yii, а вот в Yii там для рав разработки нормально поизвращались.
index0h: "Реквест ничего не делает, это набор данных без какой бы то ни было логики." - я про то, что там можно писать стандартные ларавелевские валидаторы, например exist, который делает запрос чтобы все проверить, а потом в сервисе нужно еще получить данные для манипуляций.
index0h: А как на счет ситуации с повторным запросом ? Например нужно проверить если ли такой пользователь в базе, это делает реквест, а потом в сервисе получить его данные для работы. Получается 2 запроса к бд. по сути на ровном месте. Плюс ко всему, чего я еще опасаюсь, так это того, что если я проверил в реквесте, что запись с id 7 к примеру существует, а в сервисе мне нужно достать и работать с данной записью, то я всеравно еще сделаю проверку с исключением, действительно ли все окей.
index0h: Тоесть по сути исключения посланные из сервисов считаются хорошей практикой валидации ? Я вот смотрел в эту сторону, но возникают сомнения. Если логика большая и сложная, то трай/кетч может прилично разрастись. Как на счет создать что-то типа AlertException и засовывать информацию туда, например сообщение об ошибке и код ?
Я вообще сейчас пытаюсь отказаться от моделей. Я построил некий сервис леер, однако не много не правильно сделал и вместо сущностей гоняю модели. Сейчас же весь актив рекорд потерял у меня свой смысл и инкапсулировался в репозитории ну и сущности тоже скоро ввиду.
Кастомные валидаторы это понятно, просто есть моменты когда пока не пройдет определенная логика, данные для валидации не получить. Соответственно являются ли исключения посланные из сервисов хорошей практикой валидации ?
Алексей: php.net/manual/ru/book.pdo.php еще было было не плохо и oop организовать. Не в ту сторону вы свернули при обучении. Что если ключа id в $_GET['id'] не будет ? Что если mysql_query дырявое гуано и удалено из новых версий пхп ? Что если нужно сменить базу или источник данных ? Рано вам пока код писать, почитайте литературу.
