ПГ
Size: a a a
2021 March 03
ЕР
Ivan
Там изначально кто-то говорил что 30+ сетеров это плохо. Вот и возник вопрос почему человек так думает. Если данные неотделимы друг от друга то хоть 255 если того требует логика
Во первых логика обычно таки не требует править 30 полей одновременно
Во вторых, скорее всего это неудачная логика, которую нужно декомпозировать
Во вторых, скорее всего это неудачная логика, которую нужно декомпозировать
JK
Ivan
Например есть UserProfile где есть рост,вес, цвет глаз и т.д. Какой смысл такие данные разделять на несколько сущностей?
Например есть смысл их вынести чтоб не вычитывать этот мусор из БД каждый раз когда приходит запрос и тебе нужно его авторизовать, тебе нужно только ID и признак не забанен ли пользователь. Но нет, тащим 50+ полей.
А если у тебя 100K rps, и 10 лямов пользователей, то дальше сам понимаешь как это круто всё будет работать.
А если у тебя 100K rps, и 10 лямов пользователей, то дальше сам понимаешь как это круто всё будет работать.
ЕР
Ivan
Там изначально кто-то говорил что 30+ сетеров это плохо. Вот и возник вопрос почему человек так думает. Если данные неотделимы друг от друга то хоть 255 если того требует логика
А, ну и в третьих - никакая логика не требует сеттеры
ПГ
Во первых логика обычно таки не требует править 30 полей одновременно
Во вторых, скорее всего это неудачная логика, которую нужно декомпозировать
Во вторых, скорее всего это неудачная логика, которую нужно декомпозировать
А вот смысл декомпозироваться ради декомпозиции? Чтобы потом join тащить?
ЕР
А вот смысл декомпозироваться ради декомпозиции? Чтобы потом join тащить?
Чтобы связность кода уменьшить
ЕР
Если ты декомпозировал так что тебе джоин нужен, то ты не декомпозировал, поздравляю
ПГ
Чтобы связность кода уменьшить
Связность какого кода, если это "Свойства пользователя", у которого нет логики. Если эти части требуются в разных местах - то согласен. А если нет, то не вижу смысла
ЕР
Связность какого кода, если это "Свойства пользователя", у которого нет логики. Если эти части требуются в разных местах - то согласен. А если нет, то не вижу смысла
Смотря какие свойства. Я уже писал выше - данные для аутентификации/авторизации обычно удобно таки вынести отдельно
ЕР
Контактные данные - тоже
ЕР
Если у тебя прям 30 полей для которых ничего кроме crud формочки не нужно, можно и одной сущностью, чего б нет
ПГ
Смотря какие свойства. Я уже писал выше - данные для аутентификации/авторизации обычно удобно таки вынести отдельно
Ну я думаю мы поняли друг друга, об одном и том же скорее всего говорим.
ПГ
Если у тебя прям 30 полей для которых ничего кроме crud формочки не нужно, можно и одной сущностью, чего б нет
Вот я про это
I
Смотря какие свойства. Я уже писал выше - данные для аутентификации/авторизации обычно удобно таки вынести отдельно
Фразу "Если данные неотделимы друг от друга" ты понимаешь? Зачем пытаешь придумать плохие варианты и на них сделать пример?
ЕР
Ivan
Фразу "Если данные неотделимы друг от друга" ты понимаешь? Зачем пытаешь придумать плохие варианты и на них сделать пример?
Частенько видно людей для которых "все что связано с пользователем не отделимо от User"
ЕР
В этом проблема
ЕР
Если у тебя там не crud, а есть логика, опять же, её можно пересмотреть