а сеттеры в сущностях заставляют меня грустить

https://i.ytimg.com/vi/Vq3nODjHIQY/hqdefault.jpg

Если абстрагироваться от сеттеров. А просто о флюент?

в сущности - плохо, по причинам описанным окромиусом

да и если тебе для сущности нужен флюент интерфейс - то что-то явно не так пошло

Да он нужен явно. Просто меньше текста когда сеттишь много полей.

в сущности - плохо, по причинам описанным окромиусом

О, можно ссылочку на почитать?

Да он нужен явно. Просто меньше текста когда сеттишь много полей.

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

О, можно ссылочку на почитать?

чуть выше

чуть выше

ага, понял. Думал что-то еще есть. Спасибо.

Да он нужен явно. Просто меньше текста когда сеттишь много полей.

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

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

Нута данные все равно надо метить хоть там хоть тут, нет?

Ну это ничего не меняет для меня.

Нута данные все равно надо метить хоть там хоть тут, нет?

для этого не нужны сеттеры

Ну это ничего не меняет для меня.

да я уже понял) но тогда мы имеем дело с ложным посылом. И в целом нет смысла что-либо обсуждать

@fes0r а что если нужно сделать какуе-то определенную логику для сеттера, логику будем меня везте по коду? Тогда публичные свойства просто не подходят.

@fes0r а что если нужно сделать какуе-то определенную логику для сеттера, логику будем меня везте по коду? Тогда публичные свойства просто не подходят.

а что если тебе надо сделать определенную логику при изменении 3-х свойст? что, будем добавлять проверки в каждый из этих трех сеттеров?)

Подскажите для доктрины что то такое есть? http://www.midnightcowboycoder.com/

@fes0r а что если нужно сделать какуе-то определенную логику для сеттера, логику будем меня везте по коду? Тогда публичные свойства просто не подходят.

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

@fes0r у тебя есть какой то выработанный best practice по не использованию сеттеров? Под каждую сущность делать DTO?

@fes0r у тебя есть какой то выработанный best practice по не использованию сеттеров? Под каждую сущность делать DTO?

как тебе DTO помогут?)

@fes0r у тебя есть какой то выработанный best practice по не использованию сеттеров? Под каждую сущность делать DTO?

ну там, ООП и все такое, whole value pattern, декомпозиция...

@fes0r ну мне не сложно для трёх свойств написать сеттер, для будущего изменения логики

@fes0r ну мне не сложно для трёх свойств написать сеттер, для будущего изменения логики

так может это тогда не сеттер будет?

Шо, пацаны, опять сеттеры и дто ?

так может это просто метод?)

Каждую неделю повторяется, есть best practice - нету. Есть? Нету

как тебе DTO помогут?)

Форме сеттеры нужны

геттер*

сори

Шо, пацаны, опять сеттеры и дто ?

В смысле опять?

Форме сеттеры нужны

формам не нужна обычно та же модель данных которая нужна твоей бизнес логике

В смысле опять?

Каждых 3 дня обсуждаем сеттеры и дто

Каждых 3 дня обсуждаем сеттеры и дто

Я и говорю)

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

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

Можешь пример привести или линк дать на github?

Аа лул

Можешь пример привести или линк дать на github?

нет)

Так в чем плюс публичных свойсвт?

в чем проблема написания геттера/сеттера?

если в будущем придется что-то допиливать

Так в чем плюс публичных свойсвт?

ты не понял мой поинт)

я же и инетересуюсь

все поля должны быть приватными, а методы объекта никак не должны отражать "структуру" класса, только его поведение

исключение - DTO которые по сути тупые структуры данных без поведения

их удобнее держать тупо набором публичных полей

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

выбрал путь - ложи все единообразно

формам не нужна обычно та же модель данных которая нужна твоей бизнес логике

Ну то есть под каждую форму свой дто?

Ну то есть под каждую форму свой дто?

не обязательно, зависит от задачи

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

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

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

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

Что за мост например?

Что за мост например?

хз, надо гуглить. Я видел подобные штуки, но сходу не скажу

я обычно в таких ситуациях просто firebase юзал (ибо ленивый)

Чем доктрина с формой не мост?)

много делать, медленно работает

да и зачем если я могу все то же сделать с firebase и angular/react ;)

бэкэндщики нинужны

ааа, так нам тут фронтендер смуту наводит)))

а ты пытаешься убедить себя что бэкэндщики которые пишут формы на php нужны) либо это простые формы, либо это проще сделать на фронте)

Я не пишу на ангуляре/реакте. У меня есть админка на easyadmin. Для создания crud всё что мне нужно это создать сущность и в yaml конфиге написать какие из полей админке выводить. Профит. Писать совсем не много, производительность тут вообще побоку

Я не пишу на ангуляре/реакте. У меня есть админка на easyadmin. Для создания crud всё что мне нужно это создать сущность и в yaml конфиге написать какие из полей админке выводить. Профит. Писать совсем не много, производительность тут вообще побоку

easyadmin? серьезно? грусть тоска

даже соната не такая ущербная

обоснуйте)

тебе уже приходилось там листенеры переопределять?)

ERROR: S client not available

ээ, нет. Зачем?

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

@fes0r я еще не дошел до листенеров, но easyadmin мне понравилась больше сонаты )))) Может быть "пока что".

@fes0r я еще не дошел до листенеров, но easyadmin мне понравилась больше сонаты )))) Может быть "пока что".

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

во всяком случае не так в лоб как было когда я ее пробовал

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

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

А что easyadmin делает "умного"?

Так любой инструмент можно приготовить норм, даже ларавель (trollface) Просто в случае сонаты реально нужно выучить этот кусок, ибо документация скудная, код сложный для понимания. Я не осилил его(сонату) продебажить )))) слишком уныло. А вот easyadmin легче идет

Считывает mapping доктрины и угадывает какой form type поставить?)

Считывает mapping доктрины и угадывает какой form type поставить?)

это за тебя symfony/forms делает.

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

и делает все само и в рантайме

хочешь что-то подменить - добро пожаловать в нутро

Но опять же, не стоит юзать ни сонату ни easyadmin для того, над чем ты не имеешь бизнесс контроля. Если могут приходить требования бизнесса к этим админкам - то лесом. Лучше отдельный фронт.

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

В easyadmin почти каждый кусочек можно удобно подменить, и почти обо всём можно узнать из документации

если мне надо тупой crud например что бы данные какие-то залить - мне проще вообще ничего не писать а заюзать какую-нибудь headless cms

где можно админку "мышкой" накликать.

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

Поэтому я так и говорю - если бизнесу пох на админку, то easy быстрее сонаты идет. Я накидал ни разу не ковыряясь(до этого) за 1 час. Вроде как норм затраты. Headless cms ну ХЗ )))) Удачи

Но опять же, не стоит юзать ни сонату ни easyadmin для того, над чем ты не имеешь бизнесс контроля. Если могут приходить требования бизнесса к этим админкам - то лесом. Лучше отдельный фронт.

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

?

@fes0r фесор. Т.е. ты считаешь, что у сущности должны быть поля и методы, которые содержат в себе какую-то логику заполнения свойств сущности ? Без геттеров и сеттеров ?

@fes0r фесор. Т.е. ты считаешь, что у сущности должны быть поля и методы, которые содержат в себе какую-то логику заполнения свойств сущности ? Без геттеров и сеттеров ?

прикинь, объект называется. данные и логика обработки этих данных)

прикинь, объект называется. данные и логика обработки этих данных)

пасиба кэп

прикинь, объект называется. данные и логика обработки этих данных)

а нафига ДТО тогда ?

а нафига ДТО тогда ?

воспринимай их как примитив)

определенная структура данных

не объект

воспринимай их как примитив)

чтобы объект не коверкать что ли ?

что бы различать, цели у этих штук абсолютно разные

что бы различать, цели у этих штук абсолютно разные

тогда объясни, пожалуйста, накой черт нужно ДТО. А лучше ссылкой ткни

знаю, они у тебя есть