« Rev
@symfony_ru   17
Fwd »


Aleksandr
вы что-то путаете
Aleksandr
это же ну уйй))
Alexander
Ну была ситуация, когда есть fallback роут /{url}, надо чтоб он был в самом конце. Если роуты в аннотациях, то так сделать не получится
Nikolay
ага, все ошибаются - а вот мы тут самые умные
Nikolay
контроллеры как сервисы - ну чо норм, ещё в 2013 проходили это https://knpuniversity.com/screencast/question-answer-day/controllers-services
Ivan
странно, но доктрина сама юзает аннотации в хвост и гриву
Aleksandr
можно спорить бесконечно
Виталий
Всем привет. Ребят, такой вопрос. Вот есть сущность User который имплементирует табличку users в бд. Соответственно есть файлик User.php которая обрисовывает структуру таблички и имеет геттеры/сеттеры. Я хочу из контроллера вызывать что то вроде $user->notify('какой-то текст');, по вызову метода, юзеру уходит оповещение в виде смс на телефон. Как это правильней всего оформить? Ведь в Entity таким методам не место.. Сама отправка оповещения реализована сторонней библиотекой.
Ivan
через сервис
Виталий
То есть мне для каждой сущности ещё сервис делать для поддержки толстых методов?
Виталий
И как это будет в контроллере выглядеть примерно? Доку почитал, но реальных примеров реализации найти не могу
Aleksandr
можно сервис, можно события
Aleksandr
this->get('notifications')->userSms($user)
Nikolay
То есть мне для каждой сущности ещё сервис делать для поддержки толстых методов?
в сущьностях в идеале вообще не должно быть методов с имплементацией более пары строк и внешними зависимостями от сервисов
Aleksandr
там тоже люди логику умудряются тулить))
Nikolay
там тоже люди логику умудряются тулить))
им просто нужно было брать laravel - там просто рай для возможности говнокодить
Aleksandr
уйй ещё больший
Nikolay
yii2 я не смотрел, поэтому про него говорить не могу
Aleksandr
да почти одно и тоже с 1
Rodion
почитай Matthias Noback - A Year With Symfony
Rodion
а тебе надо просто сервис сделать
Nikolay
почитай Matthias Noback - A Year With Symfony
документацию следует читать - а когда она отскакивает уже от зубов - можно и книги
Rodion
в доке не писано про доменные менеджеры
Rodion
так же как и про хендлеры форм
Виталий
Если бы в доке были бы описаны примеры из практики, не было бы глупых вопросов
Rodion
да складно
Nikolay
да складно
очень складно :) давай страницу чудо книжки где есть эта инфа
Rodion
https://www.google.ru/search?q=a+year+with+symfony
Rodion
а, страницу
Rodion
глава 8, части 2 и 3
Rodion
стих 4й)
Nikolay
ох - ну если так читать - то в доках 146% ничего нет. номер страницы будет проще найти
Nikolay
в книге 8 глав? со счёта не сбился?
Rodion
не сбился
Nikolay
глав у этой книги 7, римскими цифрами обозначены. Form handlers - отличная отсебятина автора, интерфейс даже к классу написать не смог Domain managers - тоже самое, только ещё с налётом DDD
Rodion
интересное мнение
Nikolay
if (!$request->isMethod('POST')) { return false; } $form->bind($request); if (!$form->isValid()) { return false; } boilerplate code как был - так остался всё ради тонкого контроллера - так можно просто в сервис вынести код и "будет всё по феншую". разницы где говнокодить в методе контроллера или в специальном классе - нет
Rodion
именно ради тонкого контроллера
Rodion
у тебя контроллер получает реквест, "как-то" обрабатывает "данные" на его основе, формирует и возвращает респонс. обработка данных на основе реквеста - дело сервисов.
Nikolay
именно ради тонкого контроллера
тонким он в какой момент становится? каков критерий?
Rodion
когда в нем не содержится логики, не относящейся к его назначению.
Ivan
контроллеры надо делать для api и для server render отдельно или есть другие подходы?
Ivan
вот думаю зафигачить в одно или лучше разделить, и при этом чтобы не пришлось дублировать
Rodion
RESTful API подразумевает только один url для доступа к репрезентации ресурса
Rodion
но многим по большей части похер на это правило
Rodion
или разделяют из удобства
Nikolay
когда в нем не содержится логики, не относящейся к его назначению.
получение данных из формы это зона ответственности контроллера.
Ivan
это скорее для админки и бэкофиса
Ivan
на будущее, сейчас я апи делать не буду, но нужно продумать так, чтобы потом полпроекта не переписываать)
Nikolay
на будущее, сейчас я апи делать не буду, но нужно продумать так, чтобы потом полпроекта не переписываать)
завтра может не случится для проекта, за пол года не наговнокодить много
Ivan
ну может я зря загоняюсь, действительно. Преждевременная оптимизация то ещё болото
Nikolay
ну может я зря загоняюсь, действительно. Преждевременная оптимизация то ещё болото
потребуется апи - будет уже код по которому будет ясно как жить. если совсем край будет - начнешь изголяться с аннотациями и событиями контроллера, вот это будет царский говнокод ;)
Aleksandr
jsonapi.org
Rodion
можно обойтись одним сервисом. и метод notify некорректно будет применять модели пользователя.
Nikolay
обажаю ооп, хвост виляет собакой
Rodion
угу, натягивание кода на понятия
Rodion
бля
Rodion
1. у юзера нет поведения notify, он не может нотифицировать. его может нотифицировать что-то. например, Смс-нотификатор. SmsNotifier::notifyUser(UserInterface $user, string $message) 2. используй контейнер сервисов для инстанцирования и получения сервиса, чтобы не плодить экземпляры класса сервиса по всему коду. и это не единственное его преимущество.
Rodion
зачем выносить получение сервиса в отдельный метод?)
Rodion
то же самое с текущим юзером сессии.
Rodion
наследнике? свою реализацию?
Rodion
редкие юз кейсы
Nikolay
где тут смайлик с попкорном
Dmitriy
Dmitriy
пойдет ?
Nikolay
Nikolay
пойдет ?
спс
Nikolay
кроме sylius в жизни то чтото видел?
Artur
О
Artur
Чатик та живой
Aleksandr
так этож хорошо)
Aleksandr
и всё же, почему везде в пример Sylius?
Aleksandr
даешь дискусию!
Aleksandr
судя по гисту, ты собрался инжектить сервис в сущность?
« Rev
@symfony_ru   17
Fwd »