Архитектура. Насколько правильно хранить в Entity данные, не относящиеся к БД?
Всем привет!
Пишу приложение на Spring Boot/Spring Data.
Допустим, у меня есть "модельный" класс, который Entity. Его поля соответствуют полям записей в БД и читаются обычным способом через репозиторий.
Я хочу добавить в этот класс ряд полей, которых нет в БД (объявить их как Transient) и которые мне нужны для хранения промежуточных значений, флагов и т.п. Мне это удобно т.к. проще работать с единым объектом чем с двумя/тремя. Но насколько это правильно с т. зр. архитектуры? Так вообще делают? Какие тут могут полезть проблемы? И если не так, то как обычно решают такие задачи?
Если вы в одиночку разрабатываете это приложение, то можете делать, как вам удобно.
Если в команде, то старайтесь делать так, как удобно команде. А как удобно конкретной команде разработчиков - нужно спросить у команды.
Пока то, что вы описываете, можно охарактеризовать, как отсутствие архитектуры. Это тех.долг, но это не приговор, с этим многие живут, пока приложенеие маленькое, несложное.
hint000, Так я и спрашиваю - как правильно выстроить архитектуру? Разрабатываю один, но вероятно что использовать этот код будет кто-то в дальнейшем. Собственно, хочется не велосипед строить, а сделать так как принято - чтобы было понятно, правильно и без техдолга. Если есть уточняющие вопросы - готов ответить.
Его поля соответствуют полям записей в БД и читаются обычным способом через репозиторий
У вас в джаве есть ORM Hibernate, возьмите ее
Она представляет дата-маппер, то есть вы пишите бизнес-объект, работаете с ним, а когда надо замаппить часть или все его поля — пишите маппинг (за счет конфигов/аннотаций)
Wan-Derer, невозможно дать общий ответ. У каждого приложения архитектура может быть разная. Научиться делать хорошую архитектуру - это примерно как начиться составлять алгоритмы, только это следующий уровень мастерства. Никто вас этому не научит. Но вы можете научиться на чужих примерах. Когда работаете с чужим кодом, то замечаете недостатки и потом стараетесь не повторять их в своём коде. Хорошее тоже замечаете.
В целом хорошо, что вы об этом задумываетесь. Но повторю, в общем виде никто ответ не даст. Требуется code review, а значит требуется ваш код, и кто-то должен потратить время.
Максим Федоров, Приложение на Spring (Spring Data) где уже есть Hibernate. Всё так и есть - маппинг, аннотации. Вопрос насколько правильно то что "бизнес-объект" и "DAO-объект" - одно и то же.
Wan-Derer, пожалуй это неправильно, рекомендуют на каждом слое заводить свои объекты,
как раз подходит для случая когда бизнес объект собирается из нескольких источников
Wan-Derer, ну вообще как бы "неправильно", но в реальной жизни возможно. Раз ты спрашиваешь как делать, значит проблем у тебя с этим нет. Ну разобьешь ты на две сущности, и какие это решит проблемы у тебя? Обычно разбивают если это супер большой монолит
"бизнес-объект" и "DAO-объект"
то о чем ты говоришь не дао. Разберись в терминологии
Jacen11, Хотелось бы понять какие именно проблемы такой подход может вызвать в более крупных приложениях. Ну и избежать строительства велосипедов, т.е. для типовых задач использовать типовые подходы.
В принципе можно, никто вас за такое не расстреляет. Проблемы - тут все зависит от масштаба вашего приложения и требований к дальнейшей поддержке и изменениям в коде. Чего-то прямо серьезного, что вылезет всегда или почти всегда я в этой истории не наблюдаю.
Средний
Простой
