Семен Киреков - Spring, Hibernate, паттерн Value Object и границы его применения
Vložit
- čas přidán 11. 09. 2024
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
При разработке ПО всегда заходит вопрос о валидации и корректной работе с данными. Если выполнить бизнес-операцию с неверными входными данными, которые передал пользователь, последствия могут быть плачевными.
Спикер расскажет:
- Что такое паттерн Value Object?
- Как внедрить Value Object в стеке Spring/Hibernate?
- Что о Value Object думают признанные эксперты в IT-индустрии?
- Когда применение Value Object может помешать дальнейшей разработке?
Презентация к докладу: squidex.jugru....
О чем тема? Смешать слой бд и бизнес валидацию и пытаться в этом найти положительные моменты? Бессмыслица какая то
всё выступление думал об этом
Практически все значения могут стать невалидными, особенно если не продумать ограничения в самом начале, и потом исправить это будет очень сложно, даже если вы данными владеете. Если от ваших данных кто-то сильно зависит, то это отдельная проблема сама по себе. Значения не обязательно должны быть максимально валидными, плюсы от их использования сохраняются. Дополнительная валидация понадобится в любом случае, если данные будут пересекать границы системы.
В докладе озвучены проблемы, связанные не столько с самим value object, сколько с валидацией, персистенцией и управлением изменениями. Если вы персистете entity, то безопасным изменением будет только добавление нового поля. Любое изменение уже существующего влечет контролируемую миграцию. Даже если вы не используете value object, или валидацию через JSR303, и лишь немного поменялось назначение поля без изменения формата, нужно исследовать все эффекты, которые может дать это изменение.
30:50 Точно так же можно данные сложить в объект. Просто преобразованием/валидацией сырых данных будет заниматься не конструктор/статический метод, а сервис/фабрика.
Соглашусь с комментариями выше и добавлю. Недавно смотрел лекции на Dddevotion там был классный пример в котром персистетный уровень разделен с уровнем бизнес логики и все value object были именно в слое бизнес логики, это дает преимущество в том что если менять бд с постгрес на монгу например то это никак не коснется уровня бизнес логики. Там была смесь ddd и clean architecture.
у меня так на проекте, есть 3 вида моделей dto,model (в логике) и entity
Value Object надо относится как к enum, и уж темболее не перекладывать всю валидацию в него.
по сути енум и есть примитивный валуе обжект