В итоге придется отдельно все импортировать каждый контроллер, что по сути так на так

/foo/bar, /foo/{name}

импортировать куда и зачем?

насчёт импорта тоже не понял. в документацию для фронтендера что ли?

т.е. не получится импортировать роуты так: resource: '@AppBundle/Controller/', придется прописывать отдельно каждый контроллер, если могут возникнуть коллизии

ну как по мне, звучит как надуманная проблема

симфони и логика в контроллерах?)

вы что-то путаете

это же ну уйй))

Ну была ситуация, когда есть fallback роут /{url}, надо чтоб он был в самом конце. Если роуты в аннотациях, то так сделать не получится

ага, все ошибаются - а вот мы тут самые умные

контроллеры как сервисы - ну чо норм, ещё в 2013 проходили это https://knpuniversity.com/screencast/question-answer-day/controllers-services

странно, но доктрина сама юзает аннотации в хвост и гриву

можно спорить бесконечно

Всем привет. Ребят, такой вопрос. Вот есть сущность User который имплементирует табличку users в бд. Соответственно есть файлик User.php которая обрисовывает структуру таблички и имеет геттеры/сеттеры. Я хочу из контроллера вызывать что то вроде $user->notify('какой-то текст');, по вызову метода, юзеру уходит оповещение в виде смс на телефон. Как это правильней всего оформить? Ведь в Entity таким методам не место.. Сама отправка оповещения реализована сторонней библиотекой.

через сервис

Всем привет. Ребят, такой вопрос. Вот есть сущность User который имплементирует табличку users в бд. Соответственно есть файлик User.php которая обрисовывает структуру таблички и имеет геттеры/сеттеры. Я хочу из контроллера вызывать что то вроде $user->notify('какой-то текст');, по вызову метода, юзеру уходит оповещение в виде смс на телефон. Как это правильней всего оформить? Ведь в Entity таким методам не место.. Сама отправка оповещения реализована сторонней библиотекой.

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

То есть мне для каждой сущности ещё сервис делать для поддержки толстых методов?

И как это будет в контроллере выглядеть примерно? Доку почитал, но реальных примеров реализации найти не могу

можно сервис, можно события

this->get('notifications')->userSms($user)

То есть мне для каждой сущности ещё сервис делать для поддержки толстых методов?

в сущьностях в идеале вообще не должно быть методов с имплементацией более пары строк и внешними зависимостями от сервисов

там тоже люди логику умудряются тулить))

там тоже люди логику умудряются тулить))

им просто нужно было брать laravel - там просто рай для возможности говнокодить

уйй ещё больший

yii2 я не смотрел, поэтому про него говорить не могу

да почти одно и тоже с 1

То есть мне для каждой сущности ещё сервис делать для поддержки толстых методов?

это называется Domain Manager

почитай Matthias Noback - A Year With Symfony

а тебе надо просто сервис сделать

почитай Matthias Noback - A Year With Symfony

документацию следует читать - а когда она отскакивает уже от зубов - можно и книги

в доке не писано про доменные менеджеры

так же как и про хендлеры форм

Если бы в доке были бы описаны примеры из практики, не было бы глупых вопросов

Если бы в доке были бы описаны примеры из практики, не было бы глупых вопросов

http://symfony.com/doc/current/email.html#sending-emails строка 26

так же как и про хендлеры форм

даладно

да складно

да складно

очень складно :) давай страницу чудо книжки где есть эта инфа

https://www.google.ru/search?q=a+year+with+symfony

а, страницу

глава 8, части 2 и 3

стих 4й)

ох - ну если так читать - то в доках 146% ничего нет. номер страницы будет проще найти

в книге 8 глав? со счёта не сбился?

не сбился

глав у этой книги 7, римскими цифрами обозначены. Form handlers - отличная отсебятина автора, интерфейс даже к классу написать не смог Domain managers - тоже самое, только ещё с налётом DDD

интересное мнение

if (!$request->isMethod('POST')) { return false; } $form->bind($request); if (!$form->isValid()) { return false; } boilerplate code как был - так остался всё ради тонкого контроллера - так можно просто в сервис вынести код и "будет всё по феншую". разницы где говнокодить в методе контроллера или в специальном классе - нет

именно ради тонкого контроллера

у тебя контроллер получает реквест, "как-то" обрабатывает "данные" на его основе, формирует и возвращает респонс. обработка данных на основе реквеста - дело сервисов.

именно ради тонкого контроллера

тонким он в какой момент становится? каков критерий?

когда в нем не содержится логики, не относящейся к его назначению.

контроллеры надо делать для api и для server render отдельно или есть другие подходы?

вот думаю зафигачить в одно или лучше разделить, и при этом чтобы не пришлось дублировать

RESTful API подразумевает только один url для доступа к репрезентации ресурса

но многим по большей части похер на это правило

или разделяют из удобства

когда в нем не содержится логики, не относящейся к его назначению.

получение данных из формы это зона ответственности контроллера.

контроллеры надо делать для api и для server render отдельно или есть другие подходы?

требования к версированию апи есть?

требования к версированию апи есть?

пока нет

это скорее для админки и бэкофиса

на будущее, сейчас я апи делать не буду, но нужно продумать так, чтобы потом полпроекта не переписываать)

на будущее, сейчас я апи делать не буду, но нужно продумать так, чтобы потом полпроекта не переписываать)

завтра может не случится для проекта, за пол года не наговнокодить много

ну может я зря загоняюсь, действительно. Преждевременная оптимизация то ещё болото

ну может я зря загоняюсь, действительно. Преждевременная оптимизация то ещё болото

потребуется апи - будет уже код по которому будет ясно как жить. если совсем край будет - начнешь изголяться с аннотациями и событиями контроллера, вот это будет царский говнокод ;)

jsonapi.org

можно обойтись одним сервисом. и метод notify некорректно будет применять модели пользователя.

обажаю ооп, хвост виляет собакой

угу, натягивание кода на понятия

бля

1. у юзера нет поведения notify, он не может нотифицировать. его может нотифицировать что-то. например, Смс-нотификатор. SmsNotifier::notifyUser(UserInterface $user, string $message) 2. используй контейнер сервисов для инстанцирования и получения сервиса, чтобы не плодить экземпляры класса сервиса по всему коду. и это не единственное его преимущество.

зачем выносить получение сервиса в отдельный метод?)

то же самое с текущим юзером сессии.

наследнике? свою реализацию?

редкие юз кейсы

где тут смайлик с попкорном

пойдет ?

пойдет ?

спс

кроме sylius в жизни то чтото видел?