на вот

возьми это упражнение

придумай себе маленькую задачку (описать объектами например заказ и что с ним могут делать)

и попробуй соблюсти все эти ограничения

они тут жесткие сильно, специально что бы ты вопросы начал нужные задавать

Да вот последние пункты уже )

С первыми уже все понятно. И на тысячи строк кода может 1 else

От зенда был такой доклад как код делать читаемым. Все найти не могу

С первыми уже все понятно. И на тысячи строк кода может 1 else

ну это самое простое из ограничений)

1. "уникальный email" не является бизнес ограничением на саму сущность, скорее на коллекцию сущностей 2. этот вопрос тебе надо было с бизнесом решить. Что делать с пользлователями которые не указали ранее возраст

если я правильно тебя понял - все что я могу сделать: 1) в сущности максимум что я могу сделать проверить что это впринципе чтото похожее на емейл (для простоты что это не пустая строка) 2) само ограничение что емейл должен быть уникальным среди емейлов других пользователей вынести в отдельный сервис редактирования пользователя, который: - принимает сущность пользователя и мыло - проверяет мыло на уникальность и если все ок - меняет мыло через changeMail сущности

если я правильно тебя понял - все что я могу сделать: 1) в сущности максимум что я могу сделать проверить что это впринципе чтото похожее на емейл (для простоты что это не пустая строка) 2) само ограничение что емейл должен быть уникальным среди емейлов других пользователей вынести в отдельный сервис редактирования пользователя, который: - принимает сущность пользователя и мыло - проверяет мыло на уникальность и если все ок - меняет мыло через changeMail сущности

1. да, пользователя волнует что у него email. А может даже это его не волнует) Может это тебя волнует что бы спамить его) 2. как думаешь, кто представляет "коллекцию юзеров"?

2. репозиторий. Т.е. по факту можно попробовать просто найти чувака с таким мылом

2. репозиторий. Т.е. по факту можно попробовать просто найти чувака с таким мылом

я так понимаю метода add(User $user) у тебя там пока нет) потому наверное такие предложения)

да, такого метода пока нет. Но если честно не до конца улавливаю сейчас связь add при попытке изменить мыло и именно в таком формате add(User $user)

да, такого метода пока нет. Но если честно не до конца улавливаю сейчас связь add при попытке изменить мыло и именно в таком формате add(User $user)

а, изменить мыло... тут да

ну и в целом для UI придется проверять

но допустим я создаю пользователя, а не изменяю

и мыло у меня уникальным должно быть и оно обязательно

тогда мне захочется делать чтото по типу new User($email) и в add я уже пробрасываю этого User'a

но допустим я создаю пользователя, а не изменяю

я бы делал так: - для UI отдельно http запросом проверять что email не занят - повесить на базу unique ключ и забить болт

получается ты предлагаешь внутри addUser чекать его мыло на уникальность?

я бы делал так: - для UI отдельно http запросом проверять что email не занят - повесить на базу unique ключ и забить болт

хмм даже так, получается я себе просто все усложняю?)

@sergey_smile можешь делать валидации таким образом: 1. Делаешь интерфейс аля ValidateableDatabasedly. 2. Екстендишь ентити от этого интерфейса и делаешь метод isValid() 3. В этом методе возвращаешь массив с ошибками. 4. На preFlush ставишь листенер который слушает или тебе пришла ентитя которая инстанс оф интерфейса. 5. Там вызываешь isValid() и если не пусто - throw Exception или что там тебе нужно. 6. Потом кетчишь этот ексепшн и даёшь пользователю сообщение в гуи

в жопу префлуши ваши

@sergey_smile можешь делать валидации таким образом: 1. Делаешь интерфейс аля ValidateableDatabasedly. 2. Екстендишь ентити от этого интерфейса и делаешь метод isValid() 3. В этом методе возвращаешь массив с ошибками. 4. На preFlush ставишь листенер который слушает или тебе пришла ентитя которая инстанс оф интерфейса. 5. Там вызываешь isValid() и если не пусто - throw Exception или что там тебе нужно. 6. Потом кетчишь этот ексепшн и даёшь пользователю сообщение в гуи

тут у меня еще больше вопросов возникает. 1) Что будет внутри isValid? Проверка всей сущности на валидность? 2) Как isValid будет проверять на уникальность мыла? Ходить в репозиторий и чекать есть ли у меня чувак с таким мылом? Както слишком много будет уметь делать этот isValid 3) Если вешать isValid на preFlush и валидировать весь обьект полностью каждый раз только перед flush - на сколько в этом есть смысл, если я меняю одно свойство? и что мне делать по всему приложению, если в таком случае я допускаю что у меня может бродить там невалидный обьект?

в жопу префлуши ваши

аргументированно )

мнение Ocramius'а - агрумент?

тут у меня еще больше вопросов возникает. 1) Что будет внутри isValid? Проверка всей сущности на валидность? 2) Как isValid будет проверять на уникальность мыла? Ходить в репозиторий и чекать есть ли у меня чувак с таким мылом? Както слишком много будет уметь делать этот isValid 3) Если вешать isValid на preFlush и валидировать весь обьект полностью каждый раз только перед flush - на сколько в этом есть смысл, если я меняю одно свойство? и что мне делать по всему приложению, если в таком случае я допускаю что у меня может бродить там невалидный обьект?

1) да 2) в репо точна не должна ходить ) тогда другой вариант. Создаёшь отдельный сервис-валидатор и там валидируешь что хочешь у своей ентити. Укажешь конкретно какой валидатор на какой ентите висит 3) да, весь объект полностью. Мыло к примеру можешь не валидировать если оно не изменилось. Не валидные объекты ты не можешь допускать никак. У тебя получается инконсистентность. Так нельзя делать. Пришл невалидный объект - пока не сделаешь валидным - нельзя сейвить в базу.

аргументированно )

https://github.com/symfony/symfony-docs/issues/5315

https://github.com/symfony/symfony-docs/issues/5315

тыкни пальцем куда именно смотреть плиз

3 пункт списка

1) да 2) в репо точна не должна ходить ) тогда другой вариант. Создаёшь отдельный сервис-валидатор и там валидируешь что хочешь у своей ентити. Укажешь конкретно какой валидатор на какой ентите висит 3) да, весь объект полностью. Мыло к примеру можешь не валидировать если оно не изменилось. Не валидные объекты ты не можешь допускать никак. У тебя получается инконсистентность. Так нельзя делать. Пришл невалидный объект - пока не сделаешь валидным - нельзя сейвить в базу.

Если я не могу допускать невалидные обьекты и делаю сервис валидатор, то выходит в идеале этот валидатор надо запускать после каждого изменения обьекта и за этим нужно следить вручную. Тогда возможно проще делать сервис редактирования пользователя, где есть changeMail, который внутри чекает мыло и если с мылом все ок - то вызывает изменение его в сущности? Как профит вижу: - не запускать валидатор - вприцнипе нет момента, когда у меня есть обьект с дублирующимся мылом Из минусов: - все также нужно полагаться, что никто не херанет изменение мыла в сущности на прямую в обход сервиса и это лежит чисто на совести разраба

3 пункт списка

а есть объяснение почему ?

Если я не могу допускать невалидные обьекты и делаю сервис валидатор, то выходит в идеале этот валидатор надо запускать после каждого изменения обьекта и за этим нужно следить вручную. Тогда возможно проще делать сервис редактирования пользователя, где есть changeMail, который внутри чекает мыло и если с мылом все ок - то вызывает изменение его в сущности? Как профит вижу: - не запускать валидатор - вприцнипе нет момента, когда у меня есть обьект с дублирующимся мылом Из минусов: - все также нужно полагаться, что никто не херанет изменение мыла в сущности на прямую в обход сервиса и это лежит чисто на совести разраба

что если другой разраб не будет знать о существовании твоего сервиса и будет сохранять ентити юзера напрямую через $this->em->persist($user); ?

имхо - нарушение SRP плюс там есть ссылка на саму презентацию в начале сообщения, там чуть больше рассказано это ведь ещё и смесь слоя приложения и слоя логики

что если другой разраб не будет знать о существовании твоего сервиса и будет сохранять ентити юзера напрямую через $this->em->persist($user); ?

ну в этом случае да, preFlush спасает

имхо - нарушение SRP плюс там есть ссылка на саму презентацию в начале сообщения, там чуть больше рассказано это ведь ещё и смесь слоя приложения и слоя логики

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

что если другой разраб не будет знать о существовании твоего сервиса и будет сохранять ентити юзера напрямую через $this->em->persist($user); ?

для этого есть код ревью

вы не защитите код от кодера

а что если другой разраб выпилит нах ваш ивент листенер?

парни заюзал symfony DI в своем проекте, и такой вопрос тепреь как мне в шторме автодополнение в yaml сделать без symfony плагина?

а что если другой разраб выпилит нах ваш ивент листенер?

Для это пишется юнит тест

Хотя и тест сможет удалить)

вот именно

поэтому спасет только надавать по щщам на ревью

Ну я бы не делал сервис отдельный, а делал универсально через листенер

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

в них придется выносить логику

http://ocramius.github.io/doctrine-best-practices/#/58 начиная отсюда

иначе очень быстро наткнетесь на циклические зависимости

Lifecycle Callbacks are supposed to be the ORM-specific serialize and unserialize

есть сервис, он юзает орм, есть листнер доктрины, он юзает сервис, в итоге чтоб инициализировалась доктрина, становится нужен этот сервис, которому нужна доктрина

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

и свои ивенты диспатчить

ес надо

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

предусмотрительно))

@sergey_smile можешь делать валидации таким образом: 1. Делаешь интерфейс аля ValidateableDatabasedly. 2. Екстендишь ентити от этого интерфейса и делаешь метод isValid() 3. В этом методе возвращаешь массив с ошибками. 4. На preFlush ставишь листенер который слушает или тебе пришла ентитя которая инстанс оф интерфейса. 5. Там вызываешь isValid() и если не пусто - throw Exception или что там тебе нужно. 6. Потом кетчишь этот ексепшн и даёшь пользователю сообщение в гуи

ValidateableDatabasedly че?

есть сервис, он юзает орм, есть листнер доктрины, он юзает сервис, в итоге чтоб инициализировалась доктрина, становится нужен этот сервис, которому нужна доктрина

вывод - не юзай доктриновские ивент листенеры

@fes0r мой довод насчет srp относительно ивент листенеров хоть в тему?) а то мало ли, вдруг я что-то не так понимаю

вывод - не юзай доктриновские ивент листенеры

я об этом и говорю, зачем делать тот же самый вывод еще раз?

я об этом и говорю, зачем делать тот же самый вывод еще раз?

не заметил)

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

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

и свои ивенты диспатчить

ес надо

вобщем впечатления плохие))

ERROR: S client not available

я могу ошибаться, но в таком случае вся логика определения формы должна быть внутри формы. И вставить костыль, типа как сделать какое-то поле disabled уже не получится (такое, например, актуально когда на edit нужно что-то запретить редактировать). Выходит, что придется инжектить еще и роутер, чтобы определить где мы сейчас есть, я прав?

жуть какая

disabled = data->getId() ? true : false

ой, некропостинг какой-то

ой, некропостинг какой-то

Если сущность создаётся с id, мм?

@sergey_smile можешь делать валидации таким образом: 1. Делаешь интерфейс аля ValidateableDatabasedly. 2. Екстендишь ентити от этого интерфейса и делаешь метод isValid() 3. В этом методе возвращаешь массив с ошибками. 4. На preFlush ставишь листенер который слушает или тебе пришла ентитя которая инстанс оф интерфейса. 5. Там вызываешь isValid() и если не пусто - throw Exception или что там тебе нужно. 6. Потом кетчишь этот ексепшн и даёшь пользователю сообщение в гуи

Угу. Видел такое. Кажется в фальконе. Аа, магия-ивенты 'beforeValidation', 'validation', 'after...', 'beforeSave'

И это ну совсем ни к чему хорошему не приводит

жуть какая

перечитайте контекст проблемы. при определении формы, как сервис, у Вас нет доступа к билдеру, емнип

почему для подключаемых бандлов рекомендуют использовать xml для конфига? а для своих - yaml

расширяемость лучше

в каком конкретно юзкейсе xml будет более расширяемым, нежели yaml?

http://fabien.potencier.org/symfony-service-container-using-xml-or-yaml-to-describe-services.html

почему для подключаемых бандлов рекомендуют использовать xml для конфига? а для своих - yaml

где написано что ямл для своих?

слышал только Аннотации для своих

:)

да и вообще да, аннотации для своих проектов

Аннотации для своих банднов это про доктрину

еще есть роутинги, валидации и целая тележка аннотаций

так что не только

А человек видимо про сервисы спросил

в бест практисах не нашел, но я имею ввиду конкретно конфиги сервисов

Аннотации для своих банднов это про доктрину

а роутинг

роутинг - имхо дело вкуса

Ну вот конкретно про "аннотации в своих бандлах, xml в библиотеках" говорил окрамиус про доктрину

http://fabien.potencier.org/symfony-service-container-using-xml-or-yaml-to-describe-services.html

это все же трошки устаревшая инфа насчет автокомплита - симфони плагин во многих случаях вытягивает все, что нужно валидация - ну, в ide не подсвечивается, но при проверке ошибка сразу выскочит скорость работы - в любом случае влияет только на скорость сборки контейнера внешние зависимости - в принципе, действительно аргумент, но я слабо верю в то, что у кого-то в достаточно большом приложении с множеством разных бандлов какой-то из них не потянет за собой парсер yaml

не все юзают пхп шторм и уж тем более плагин симфони

+

валидация ide и валидация xml это немного разные вещи

были у нас Саблаймолюбители

боль

а xml пхп разбирает быстрее чем yaml, как минимум потому что юзает сишные биндинги для этого

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