(entities)?
я считаю что разумно оставить только геттеры (только тех полей, имеющих смысл в бизнес-логике: какие-то служебные для внутренних нужд, хотя они редко встречаются в сущностях, должны остаться скрытыми), как паттерн контроля над мутациями
под сеттерами же обычно скрывается причина, по которой то или иное поле изменяется. Обычно эта причина, как отметил Сергей, отползает подальше от данных в т.н. сервисы, или даже контроллеры. Обычно такой сервис / контроллер дёргает несколько сеттеров за раз. Разумно тогда их объединить в один осмысленный метод в самой сущности.
Плохо это. Обычно когда достали с базы сущность то ни кто не лочит ответствующий строку в базе. Тоесть мы получаем устаревшие данные потенциально. Далее раз там гетеры то мы используем УСТАРЕВШИЕ данные для логики а значит ломаем логику и получаем баги. Плюс такой себе глобальный стейт Кто угодно где угодно может достать сущность из репы условной и получить доступ к стейту. Таким образом база как глобальный стейт для всего приложения. Хотя почему то при этом люди избегают глобальных переменных хотя это по сути одно и тоже получается.
У вас данные «устаревшие» в любом случае
Тесно связана если для одной бизнес операции начинаем использовать несколько сущностей то все приехали лочить их ни кто не будет а баги делать будут А если нет акцессоров то и использовать больше одной за раз не получится
Что-то не понятно. Для одной бизнес операции необходимо использоать несколько сущностей, вы написали есть проблема устаревания данных. Ответ - не использовать несколько сущностей, это как? Если в операции уже есть необходимость в переплетения данных, судя по ТЗ.
Разбиваем операцию на минимальные операции где мгновенное и отложенное согласование данных. Далее всё что мгновенное должно жить внутри одной капсулы/акторе и в ней работать. Всё остальное просто делается паралельно или последовательно через сообщения. Тест получаем набор операций изолированных с немедленной согласасованностью связанные отложенной согласованностью
Имеется в виду транзакция для того, что вы называете капсулой. Для остальных капсул уже свои транзакции
Не транзакции а локи. Ни кто не имеет права менять данные пока мы с из копией в оперативке рабоатем. Чтобы избежать того что наша копия будет не соотвествовать реальности
Обсуждают сегодня