я думаю ты ляжешь первым

но это больше для SPA

Ты когда нам лекарство о рака сделаешь?)

в смысле? от сеттеров ты можешь просто отказаться. Проблема отказаться от геттеров

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

Может быть, если сервис важный, то можно уделить немного времени и написать регистрацию, которая нужна именно вам? :)

я думаю ты ляжешь первым

"если я встану, то ты ляжешь"

auth0 оч потные, для среднего проекта их хватит

я думаю ты ляжешь первым

у нас ддосы от конкурентов)

но ддосы то на вас а не на них

если они слабые то будет хорошая цель)

в смысле? от сеттеров ты можешь просто отказаться. Проблема отказаться от геттеров

Я вот пропустил то обсуждение про сеттеры геттеры. А в чем их неудобство?

день сурка

ахаха

Я вот пропустил то обсуждение про сеттеры геттеры. А в чем их неудобство?

кто говорит что это неудобно? Вот у тебя есть данные, к которым ты имеешь доступ на чтение через get и на запись через set. И вот у тебя есть сервисы-менеджеры, которые хранят процедуры для работы с этими данными. Удобно ведь

Так а почему ты против то?

дело не в сеттерах

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

не оч выразительное

Так а почему ты против то?

сеттеры удобно писать но не удобно ими пользоваться спустя время. Особенно когда у тебя приложение выходит за рамки CRUD тупого

так же с точки зрения семантики кода - это бред полный.

можно просто отказаться от префиксов get и set для начала и именовать методы нормально. Этого достаточно что бы вопрос с семантикой решить

типа rename вместо setName. Тут изменения только на уровне названий

причем довольно простые изменения

ну и еще - у объектов есть жизненный цикл. Если у тебя создание сущности скажем это "сделать новый и потом через сеттеры запихнуть данные" у тебя уже не так просто будет отделить флоу создания от обновления.

а это иногда требуется

чаще будешь подгонять требования под то как у тебя код написан

над составить сравнительную таблицу всех компонентов, чтобы было понятно какие из них работают только с аксесорами, а какие умеют через рефлексию

над составить сравнительную таблицу всех компонентов, чтобы было понятно какие из них работают только с аксесорами, а какие умеют через рефлексию

зачем?

ну я вот не помню например их наизусть, но той же сонате нужны аксесоры на запись

ты не всегда можешь взять и отказаться от сеттеров

если у тебя вся работа построена на сущностях

без дополнительных маппингов на дто

ну так то да)

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

да, возможно понадобится какой-то слой трансформации данных (как в формах)

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

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

а лепить дто на каждый чих(сущность), это из разряда лепить интерфейс на каждый сервис

у меня вот на котлине нет ни сеттеров ни геттеров

а лепить дто на каждый чих(сущность), это из разряда лепить интерфейс на каждый сервис

я не леплю DTO)

у меня вот на котлине нет ни сеттеров ни геттеров

у тебя там дата классы есть...

Но сеттеры - более унифицированы и предсказуемы. Фрейм не сможет угадать что rename меняет поле name. Тем более rename - более неопределенное в целом. Если у тебя например есть поля name, businessName и shortName. Какое будет менять rename?

что значит фрейм не может угадать?

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

Зато твитну нужны геттеры

Твигу *

твигу не нужны твои сущности

а если нужны, то у тебя проблемы

Ну все через рефлексию - не самый производительный вариант порой же?

твигу не нужны твои сущности

Как уж? Он ищет getName, hasName, isName.

так не передавай свои сущности в твиг

и не будут нужны

Как уж? Он ищет getName, hasName, isName.

ну так геттеры, а не сеттеры же. сеттеры твигу не вперлись.

Здрасьте. А че каждые данные сидеть и в массивы превращать?

Как уж? Он ищет getName, hasName, isName.

ему сойдут и массивы, синтаксис от этого не изменится

Здрасьте. А че каждые данные сидеть и в массивы превращать?

не поверишь)

Я считаю, что это немного бред. :)

Зато твитну нужны геттеры

разве? вроде он с паблик полями тоже работает

Здрасьте. А че каждые данные сидеть и в массивы превращать?

в массив, в DTO, во что-то что скрывает от шаблонов структуру данных которая нужна для write операций

ты ж в json не скармливаешь весь граф своих сущностей?

разве? вроде он с паблик полями тоже работает

Паблики поля - не хорошо.

Паблики поля - не хорошо.

почему?

Паблики поля - не хорошо.

это другой вопрос

Паблики поля - не хорошо.

паблик поля хорошо когда это не объект а тупая структура данных без поведения

паблик поля хорошо когда это не объект а тупая структура данных без поведения

+

{{ foo.bar }} будет работать и если bar это публичное поле, и если есть геттер для приватного, и даже если foo это массив просто

в массив, в DTO, во что-то что скрывает от шаблонов структуру данных которая нужна для write операций

Не настолько нужная штука. Никаких особо проблем не влечет это.

ERROR: S client not available

ты ж в json не скармливаешь весь граф своих сущностей?

Это необходимость.

Это необходимость.

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

Не настолько нужная штука. Никаких особо проблем не влечет это.

ты не можешь допустить что это может стать проблемой?)

{{ foo.bar }} будет работать и если bar это публичное поле, и если есть геттер для приватного, и даже если foo это массив просто

Да я понимаю что будет.

Не настолько нужная штука. Никаких особо проблем не влечет это.

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

потому всякие эктив рекорды и придумали

ты не можешь допустить что это может стать проблемой?)

Можно допустить что любая штука станет проблемой. Вопрос в вероятности случая данной проблемы. Иначе код hello World начинает превращаться в демонстрацию паттернов.

Можно допустить что любая штука станет проблемой. Вопрос в вероятности случая данной проблемы. Иначе код hello World начинает превращаться в демонстрацию паттернов.

ну так надо думать головой) а что бы думать головой стоит знать о вариантах и уметь взвешивать риски.

ну и иногда лучше перебздеть чем недобздеть

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

Твит очень тесно связан с проектом обычно. В чем смысл перемапливать для него? Это ж не API.

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

ну и иногда лучше перебздеть чем недобздеть

Ну иногда. Но далеко не всегда. :)

Твит очень тесно связан с проектом обычно. В чем смысл перемапливать для него? Это ж не API.

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

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

Есть вещи которые стоит заранее подумать. А есть которые без проблем поправятся если понадобятся. :)

и чем это от API отличается по твоему?)

Есть вещи которые стоит заранее подумать. А есть которые без проблем поправятся если понадобятся. :)

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

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

Нет. Я к тому что это все на одном бэкэнде происходит.

Нет. Я к тому что это все на одном бэкэнде происходит.

а API происходит не на одном бэкэнде?

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

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

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

У твига нет строгой типизации. Заменить на DTO или массивы можно в любой момент. Возможно почти не меняя твиг

а API происходит не на одном бэкэнде?

Клиент твоего апи обычно немного отделен. :)

У твига нет строгой типизации. Заменить на DTO или массивы можно в любой момент. Возможно почти не меняя твиг

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

Клиент твоего апи обычно немного отделен. :)

какая разница?)

Ну тебе целый шаг маппинга надо добавить.

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

Ну тебе целый шаг маппинга надо добавить.

это не так сложно как ты думаешь)

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

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

Есть. :)

Есть. :)

и в чем она?)

это не так сложно как ты думаешь)

Я и не говорил что сложно. Я сказал что это не нужно если это явно не нужно.

Твит очень тесно связан с проектом обычно. В чем смысл перемапливать для него? Это ж не API.

1. ты не можешь больше проследить где используется то или иное поле в сущностях. их сложнее становится менять и рефакторить. твоя доменная модель уползает туда где ей не место 2. ты становишься зависим от геттеров 3. если тебе в шаблоне внутри цикла users у юзеров нужно какое-то кастомное поле, которого нет у юзера.. то первое что делают, это неперсистентное поле и туда прихают эти значения, чтобы в шаблоне все красивенько бло 4. сущности начинают подгонятся под шаблоны 5. и шаблоны это такое же отдельное приложение. представь что ты на реакте рендеришь все с предзагруженными данными