это не то?

норм будет? все правильно денормализирует?

а почему не валидную?

смотри, у тебя есть объект, с N полей. валидным он считается только если все поля заполнены. часть из них ты берешь из реквеста, за еще какой-то частью лезешь во внешний сервис. если с реквеста сходу собрать сущность - валидацию она не пройдет, потому что часть полей пусты.

object(Foo)#6 (2) { ["first"]=> int(1) ["second":"Foo":private]=> int(2) }

норм будет? все правильно денормализирует?

Jms кстати не работает с геттерами при сериализации

мы сейчас об денормализации

да, это не всегда актуально, если сущности простые, но подход с DTO из реквеста\формы гибче

смотри, у тебя есть объект, с N полей. валидным он считается только если все поля заполнены. часть из них ты берешь из реквеста, за еще какой-то частью лезешь во внешний сервис. если с реквеста сходу собрать сущность - валидацию она не пройдет, потому что часть полей пусты.

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

норм будет? все правильно денормализирует?

нужно будет потестить, спасибо public function setSecond($second) { $this->second = $second . 'alahakbar'; }

да, это не всегда актуально, если сущности простые, но подход с DTO из реквеста\формы гибче

много кода..

много кода..

разделение ответственности. сущность - твои данные в базе. DTO - данные, получаемые извне. если использовать сущность и для обработки реквеста и для сохранения базы, ты будешь менять структуру базы на каждое изменение формата данных во внешних источниках?

см. RAD

да и вообще... откуда у вас в сущности сеттеры

;)

разделение ответственности. сущность - твои данные в базе. DTO - данные, получаемые извне. если использовать сущность и для обработки реквеста и для сохранения базы, ты будешь менять структуру базы на каждое изменение формата данных во внешних источниках?

"изменение формата данных во внешних источниках" а почему формат будет менятся?

да и вообще... откуда у вас в сущности сеттеры

всегда они были и будут

а не должны быть

почему?

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

А если у тебя нет сеттеров в объектах, то что - сериализатор не использовать?

А если у тебя нет сеттеров в объектах, то что - сериализатор не использовать?

тогда только публичные свойства

тогда только публичные свойства

В сущности?

см. RAD

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

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

А у него нет. Я к этому. Я тоже через dto

"изменение формата данных во внешних источниках" а почему формат будет менятся?

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

в случае с DTO ты заменяешь поле там и в конвертере добавляешь немного логики (получить года, умножить на 12, сохранить как месяцы). в случае с сущностями ты.. мхм. мне только всякая грязь в голову приходит. логика с умножением в сеттере? менять поле в т.ч. в базе? ругаться на всех и требовать данные в старом формате?

Мне про сеттеры интересно

В сущности?

Это плохо?

Это плохо?

в теории. с ними проще, если RAD и вот это всё. но минус в том, что есть возможность получить невалидную сущность. собирать сущность через конструктор или десериализацию\денормализацию и не воздействовать на неё точечными изменениями надежнее.

Это плохо?

Ну, если в сущности публичные свойства, то должно ли это быть сущностью, а не DTO/VO?

в vo публичное свойство?) интересно

учитывая что он имутабелен

в vo публичное свойство?) интересно

Речь не о публичном свойстве, а о том, что, похоже, сущность используется не как сущность и там лучше подойдёт что-то другое. Что именно - зависит от кейса. // Я имею в виду, что похоже на то, что она используется как тупой контейнер для данных, а не как объект содержащий бизнес-логику.

Кто подскажет каких статей сравнения symfony/serializer jms/serializer thephpleague/fractal ? Ну или хоть свой опыт выбора скажите

https://blog.martinhujer.cz/symfony-forms-with-request-objects/ нормальный подход не использовать сущности в формах?

или посоветуйте статью, или пример

Ну вся суть в этой статье в этом // create an instance of an empty CreateArticleRequest $createArticleRequest = new CreateArticleRequest(); // create a form but with a request object instead of entity $form = $this->createForm(ArticleFormType::class, $createArticleRequest);

Чем плох пример из документации?

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

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

Ты смешиваешь бизнес сущность с представлением Это не есть хорошо

Что не хорошего то? Есть сущность, есть форма на ее создание. Да даже если просто генерировать CRUD, симфони сделает так что подставит enitity в форму.

Когда это нужно то вполне все удобно.

Когда это нужно то вполне все удобно.

У вас сеттеры и геттеры в сущности?

да

да

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

да

Делайте как вам удобнее.

Не, в дто

В сущности?

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

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

в случае с DTO ты заменяешь поле там и в конвертере добавляешь немного логики (получить года, умножить на 12, сохранить как месяцы). в случае с сущностями ты.. мхм. мне только всякая грязь в голову приходит. логика с умножением в сеттере? менять поле в т.ч. в базе? ругаться на всех и требовать данные в старом формате?

Вариантов решений хватает и норм решений

Речь не о публичном свойстве, а о том, что, похоже, сущность используется не как сущность и там лучше подойдёт что-то другое. Что именно - зависит от кейса. // Я имею в виду, что похоже на то, что она используется как тупой контейнер для данных, а не как объект содержащий бизнес-логику.

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

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

ужасно

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

Так это не сущность, это DTO какой-то.

это анемичная модель данных

ну то есть большинство так и делают)

ну то есть большинство так и делают)

Но где же грань?)

ужасно

почему?

Но где же грань?)

какая грань?

почему?

субъективная оценка решения. Отсутствие information hiding. Невозможность покрытия изолированными тестами. Боль

@fes0r ты бы накидал примеры в гитхабе как делать не надо и почему ))) я бы тебе огромное спасибо сказал. Анемичные модели, DTO в формах

@fes0r ты бы накидал примеры в гитхабе как делать не надо и почему ))) я бы тебе огромное спасибо сказал. Анемичные модели, DTO в формах

у меня был драфтик

Так это не сущность, это DTO какой-то.

ну а как же описание конфигураций ORM..

прям иногда хочется просто живой рабочий пример увидеть

Развели разговор с пустого места, конечно

ну а как же описание конфигураций ORM..

А что с ним не так?

Лучше помогите разобраться https://github.com/php-ds/extension/issues/106

Развели разговор с пустого места, конечно

Не в этом ли суть таких чатиков?

https://gist.github.com/fesor/370b3486cf7ee96af34fcbb286bd6563

субъективная оценка решения. Отсутствие information hiding. Невозможность покрытия изолированными тестами. Боль

думаю функциональными и юнит тестами можно спокойно покрыть

ERROR: S client not available

ну вот что-то из старого (надо перечитать)

Лучше помогите разобраться https://github.com/php-ds/extension/issues/106

Если есть желание покопаться, конечно)

думаю функциональными и юнит тестами можно спокойно покрыть

интеграционные приемочные - да. Юниты как изолированные тесты - нет

https://gist.github.com/fesor/dda6c4c37a17509f18c2c9486323d997/revisions

идти снизу вверх

А что с ним не так?

ну вот создаю я "DTO", но с приватными свойствами, сеттерами/геттерами, описываю ORM, правила валидации, сериализации.. - ну какое это дто, это сущность

прям иногда хочется просто живой рабочий пример увидеть

может быть осилю... сложно это

ну вот создаю я "DTO", но с приватными свойствами, сеттерами/геттерами, описываю ORM, правила валидации, сериализации.. - ну какое это дто, это сущность

Скорее это DTO с идентификатором.

интеграционные приемочные - да. Юниты как изолированные тесты - нет

из-за взаисмодействия с внешним хранилищем?

из-за взаисмодействия с внешним хранилищем?

из-за отсутствие какой-либо изоляции

и отсутствия возможности мокать сущности

(они ж тупо данные теперь, так что тяни их со всеми зависимостями)

чет башка не особо варит уже, с утра перечитаю)

ну короч мне не импонируют транзакционные скрипты

но я понимаю что для большинства это норм

лучше так чем по контроллерам

хотелось бы посмотреть на best practice, просто то, что я видел - это не многое

хотелось бы посмотреть на best practice, просто то, что я видел - это не многое

это не best practice.

Скорее это DTO с идентификатором.

Хотя, конечно, тут и я неправ. Это, конечно, сущность по определению. Они, всё-таки обладают идентичностью, но они анемичны.

ну то есть... а может и оно

просто так не привыкли

Вот у нас на одном проекте всё почти на анемичных моделях и там они к месту. Правда, там отчасти из-за этого и Doctrine не особо нужна.

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

а реализации уже зависят от задач, и у каждого свое видение решения

нужно будет как-то собрать пачку задач и сделать хорошие практики их решения

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

ну я анемичные модели проходил)

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

Да всё можно, по идее. У нас они, например, используются из-за того, что проект был начат с сонатой по RAD. А чтобы с сонатой без сеттеров - это огромные нагромождения на каком-то из слоёв городить.

Да всё можно, по идее. У нас они, например, используются из-за того, что проект был начат с сонатой по RAD. А чтобы с сонатой без сеттеров - это огромные нагромождения на каком-то из слоёв городить.

sensiolabs france делает отак - https://github.com/EnMarche/en-marche.fr/blob/master/src/Entity/EntityCrudTrait.php

я когда увидел - немного прифигел

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

ну и геттеры