Да не про твиг.

а про что? зачем тебе доставать данные из сущности помимо UI?

но ты с твига начал)

Ну начал - не значит что только его имел ввиду. :)

а про что? зачем тебе доставать данные из сущности помимо UI?

Для обработки например.

Для логики.

p.s. мы сейчас только про геттеры, это штуки которые имеют префикс get и являются отображением внутренней структуры класса. Есть еще query методы, которые обычно имеюот адекватное название и позволяют выполнить запрос. В некоторых ситуациях метод может просто поле вернуть, но клиентскому коду без разницы

Для логики.

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

Могу доггер повесить на доступ к полю. Могу вообще все что захошь! :))

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

Ну логика может быть завязана на разных сущностях.

Ну логика может быть завязана на разных сущностях.

часть тебе одна сущность сделает, часть другая. Все они будут входить в один агрегат. У агрегата будет корень

и через этот корень ты будешь просить что-то сделать

а еще - объекты значения, и понеслось

p.s. мы сейчас только про геттеры, это штуки которые имеют префикс get и являются отображением внутренней структуры класса. Есть еще query методы, которые обычно имеюот адекватное название и позволяют выполнить запрос. В некоторых ситуациях метод может просто поле вернуть, но клиентскому коду без разницы

Ну я не спорю. Но вот я предпочитаю унифицированность. По ней и искать легче чем по куче методов с непонятными названиями.

Ну я не спорю. Но вот я предпочитаю унифицированность. По ней и искать легче чем по куче методов с непонятными названиями.

непонятные названия = названия привязанные к твоей логике.

если они тебе не понятны - тогда вопрос снимается

Беру я сущность и сижу угадываю как разработчик назвал метод, который поле name меняет. :)

Понятно что я могу usages посмотреть.

Беру я сущность и сижу угадываю как разработчик назвал метод, который поле name меняет. :)

1. тебе IDE подскажет кто меняет это поле 2. тебе название метода подскажет зачем это происходит

Но это займёт время примерно в n раз больше.

с геттерами и сеттерами теряется информация "зачем" - это важная информация

Но это займёт время примерно в n раз больше.

2 секунды вместо одной?)

1. тебе IDE подскажет кто меняет это поле 2. тебе название метода подскажет зачем это происходит

Название метода я могу и не найти пока все методы не просмотрю.

и сэкономит тебе пару минут на то что бы понять что делает код

2 секунды вместо одной?)

Не факт. :))

Название метода я могу и не найти пока все методы не просмотрю.

ты сейчас делаешь предположения, насколько я понимаю ты с таким кодом не работал

и сэкономит тебе пару минут на то что бы понять что делает код

А с сеттерами и нетерпим надо понимать?

я работал и с таким и с таким, и я умею быстро писать код с логикой в сущностях, дробить сущности. Да, это сложно. Особенно первое время и у тебя точно первое время будет проседание по производительности труда. Но потом - разницы никакой нет

ты сейчас делаешь предположения, насколько я понимаю ты с таким кодом не работал

Ну вот беру я скажем ArrayCollection. И вот если я доку не читал. И названия методов не знаю - буду перебирать методы.

Либо гуглить.

Ну вот беру я скажем ArrayCollection. И вот если я доку не читал. И названия методов не знаю - буду перебирать методы.

а зачем тебе перебирать методы? ты должен знать что ты хочешь сделать перед тем как юзать ArrayCollection

Либо просто в массив превращать.

Ну пример не лучший. Но чтобы идея была понятна.

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

обычно все же не так происходит

Ну либо например я юзаю стороннюю.

сущность?)

типа из /vendors?)

Да блин. Ну не понимай буквально меня.

а как мне тебя понимать?

Это абстрактный пример просто чтобы идею понять.

но я не понимаю идею

так что давай конкретнее

Типа из vendors

у меня нет сущностей в vendors

а если и есть - я напрямую с ними не работаю

Ну не сущность.

Почему именно сущность?

окей, сервис. У тебя у сервиса геттеры и сеттеры есть?

Ты ж предлагаешь логику в сущности помещать.

да, именно так

Ну и соответственно тебе надо будет смотреть что сущность умеет.

На самом деле у меня палец устал печатать на телефоне. :₽

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

иначе мне эта сущность не понадобилась бы

Ну вот пришёл ты на проект.

И тебе говорят надо поменять имя юзера.

cmd + o - User - ищу поле name - делаю find usage

Ты будешь искать rename, changeName или setName?

И тебе говорят надо поменять имя юзера.

И у тебя у юзера setLastName(), setFirstName(), setSecondName()

И у тебя у юзера setLastName(), setFirstName(), setSecondName()

или так)

это к слову хороший пример)

для бизнеса эти три поля - имя

И у тебя у юзера setLastName(), setFirstName(), setSecondName()

И все предсказуемо и логично.

а ты подумаешь только о first name

или забудешь учесть middle name какой

или забудешь еще чего

И все предсказуемо и логично.

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

Не понимаю. Почему я забуду? А rename мне чем поможет?

ERROR: S client not available

и у тебя в итоге для того что бы поменять имя надо сделать 3 вызова методов. А еще веселее становится когда эти три вызова надо сделать в строгой последовательности

Не понимаю. Почему я забуду? А rename мне чем поможет?

rename($firstName, $secondName, $lastName)

он будет явно говорить о том что "имя" это все вот это

а если ваще NameVO

и у тебя в итоге для того что бы поменять имя надо сделать 3 вызова методов. А еще веселее становится когда эти три вызова надо сделать в строгой последовательности

В данном случае не вижу проблемы создать метод.

а если ваще NameVO

да, это было бы шикарно)

Но

Хотя нет.

сущности в шаблонах это боль боль.. проходили через такое

Не проходил. :)

прогеры потом говорят "проще переписать, чем переделать"

а потом переписывают также )

Сущности в API - боль. А в шаблонах - нет.

Все происходит в рамках одного реквеста на одном ПХП. В том же процессе.

Не проходил. :)

все бывает в первый раз)

Ну возможно. :)

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

Сущности в API - боль. А в шаблонах - нет.

сущность во view layer боль

Я все допускаю.

Ну у меня боли не было.

Как станет, я знаю как действовать.

Ну у меня боли не было.

давай по другому - юнит тесты пишешь? которые не на phpunit а настоящие изолированные тесты?)

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

Допускаю, что я просто не знаю, что можно круче. :)

отойдем немного от view

давай по другому - юнит тесты пишешь? которые не на phpunit а настоящие изолированные тесты?)

Да.

Подожди.

Да.

мокаешь сущности?

тестируешь геттеры/сеттеры?

Что ты имеешь ввиду изолированные а не PHPUnit?

как ты сервисы с логикой тестируешь в изоляции от сущностей и прочего?

Что ты имеешь ввиду изолированные а не PHPUnit?

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