AN
А как по папкам это все разложить, это в целом холиварная тема. Я 100500 разных репозов видел, которые кто то хвалит а кто то хейтит.
Size: a a a
2021 February 18
NS
ну типа того да. Не работать на прямую с тем что дает ОРМ. ОРМ это какой то один слой из всего. У вас все ровно должны быть какие то доменные объекты. Та же статься и рейтинги. А вот где они будут хранится и как, это уже второй вопрос. И тут уже если вам нужна консистентность на уровне БД то у вас не будет других выборов как делать типа ->hasOne в вашей орм.
Спасибо. Я вас понял
VC
Прочтите сообщение, там дфиринциальные вопросы, не ясно за что вы ратуете
Я за разделение по папкам/модулям/нэймспэйсам дажже если это не ограниченные контексты, а просто фичи
M
Добрый вечер, допустим у нас есть фреймворк с возможностью разделения на модули. Хотелось бы услышать ваше мнение стоит ли объявлять сущности внутри модулей? Или же объявить их все в "основе"?
В модуле создается интерфейс для получения/сохранения данных, а ентити его реализует. Можно между ними какой нибудь адаптер сделать при желании. Все просто )
BT
все просто и делать так не надо
BT
энтити получает и сохраняет...
M
все просто и делать так не надо
Почему не надо
VC
я б сказал что это не ответвенность ентити если не называть “сохраняет” запись в приватные поля
M
я б сказал что это не ответвенность ентити если не называть “сохраняет” запись в приватные поля
Об этом и речь. Геттеры сеттеры.
BT
ещё лучше, интерфейс для геттеров и сеттеров
M
ещё лучше, интерфейс для геттеров и сеттеров
А в чем проблема?
VC
А в чем проблема?
сеттеры и так попахивают
M
сеттеры и так попахивают
Почему?
VC
Почему?
при обычном применении делают приватные и защищенные поля публичными по сути
VC
часто не имеют никакой семантике в предметной области. Например только в каком-нибудь ЗАГСе имеет смысл операция типа $person->setFirstName();
АС
часто не имеют никакой семантике в предметной области. Например только в каком-нибудь ЗАГСе имеет смысл операция типа $person->setFirstName();
нет смысла в такой операции
потому что вместо нее будет
потому что вместо нее будет
(new LastNameChangeOperation($person))->handle($name)
в нормальном приложенииM
часто не имеют никакой семантике в предметной области. Например только в каком-нибудь ЗАГСе имеет смысл операция типа $person->setFirstName();
Семантика в доступе к данным, а больше ничего и не нужно.
КГ
нет смысла в такой операции
потому что вместо нее будет
потому что вместо нее будет
(new LastNameChangeOperation($person))->handle($name)
в нормальном приложенииА как внутри выглядит этот оперейшн?
АС
А как внутри выглядит этот оперейшн?
А какая вам разница, как его пользователю?
Внутри он инкапсулирует всё, что нужно для работы
Внутри он инкапсулирует всё, что нужно для работы
VC
нет смысла в такой операции
потому что вместо нее будет
потому что вместо нее будет
(new LastNameChangeOperation($person))->handle($name)
в нормальном приложенииочень спорно