но практика показывает что такой подход говно

а чем тебе геттеры не нравится?)

ну... тем что ты приоткрываешь доступ к состоянию объекта

смотри, если тебе надо достать кусочек стэйта сущности и сделать с ней что-то, вероятно код который это что-то делает должен лежать прямо в сущности

а если тебе надо в 10-ти местах достать этот кусочек сущности - значит что-то явно пошло не так и этот кусочек в этой сущности лежать не должен

данные должны лежать максимально рядом с кодом, который эти данные обрабатывает

с другой стороны есть toId(), когда тебе надо заменить цельную сущность на кусочек и работать только с ним. Например - использовать как идентификатор для выборки

это уже другое, ты используешь эти данные а не обрабатываешь

Оверенженеринг какой-то. Пример можно, как ты вынесешь данные из сущности и будешь хранить их там где надо?

Или пример всё тот же, список продуктов?

И сущность у нас продукт.

Оверенженеринг какой-то. Пример можно, как ты вынесешь данные из сущности и будешь хранить их там где надо?

пока нет, в соседнем чатике готовим)

может через пару неделек будет

Что за соседний?

prophp7

А почему 7? Неужели для каждой версии по чатику.

А почему 7? Неужели для каждой версии по чатику.

да нет, просто другие имена заняты были)

это люди переехавшие из gitter чата

короч мы подумали сделать мини интернет магазинчик по продаже книг

и на нем обкатывать идеи

спорить и накидывать изменения требований что бы ломать все хорошие ранее идеи

эдакий проект-упражнение

а что такого глобально плохого в грамотном использовании ORM? тот же гибер+критерия

ну будем оно все подниматься дольше, да пофиг

запросы будут генериться адекватные

а что такого глобально плохого в грамотном использовании ORM? тот же гибер+критерия

вопрос в гидрациях. Если ты будешь результат гидрировать сразу на DTO - то все збс

а если сначала на сущности а потом возиться с DTO

ну такое...

я буду отдавать объект в jsonчике и радоваться что я не фронтэндщик

ну они ангуляром каким-нибудь это все разбирают уже, хз

а как ты сущности в json превратишь?

автомэппером каким?

а если в сущности 10 полей, и они тебе нужны все... но на фронтэнде нужны только 4

или еще веселее

тебе надо список комментов и имя автора, только его имя

ты будешь отдавать вместе со связанной сущностью юзера?

а как ты сущности в json превратишь?

это ну ОЧЕНЬ легкая задача)

это ну ОЧЕНЬ легкая задача)

я привел тебе два кейса

реши их "легко"

а если в сущности 10 полей, и они тебе нужны все... но на фронтэнде нужны только 4

ну джэксон такое легко могёт

то есть твой json будет содержать все данные а они сами разберутся?

так?

и кстати такое тоже

тебе надо список комментов и имя автора, только его имя

ты будешь отдавать вместе со связанной сущностью юзера?

нет, наоборот

мой json будет содержать только то, что должен содержать мой json

как?

@JsonIgnore

окей, в одном респонсе тебе это поле не нужно, а в другом нужно

группы7

или другой кейс

две версии API

V1: { "foo": 1 } V2: { "foo": [1, 2, 3] }

реши легко

я бы указал при маппинге конкретный список полей, гугл еще говорит что есть jacksonMixIn

окей, в одном респонсе тебе это поле не нужно, а в другом нужно

мол раньше могла быть только одна штука, теперь много штук

а теперь вопрос - а разве не проще тупо взять из базы то что надо?

1. быстрее будет работать, 2. Меньше магии 3. проще в поддержке

отказаться от задачи на этапе проектирования... два апи - две программы и идите в лес

или другой кейс

две версии API

ну я не люблю в приложении в котором больше трех сущностей, трех связей и 15 полей таскать чистый SQL

а теперь вопрос - а разве не проще тупо взять из базы то что надо?

4. сущности ничего не знают о UI (аннотации хоть и являются мета информацией - это все же смешение ответственности)

что чистый SQL знает о UI? )))) :D

4. сущности ничего не знают о UI (аннотации хоть и являются мета информацией - это все же смешение ответственности)

проще в поддержке ORM, пока оно не начинает генерить дебильные запросы

1. быстрее будет работать, 2. Меньше магии 3. проще в поддержке

тут уже начинаются namedQuery и по сути тот же SQL, что отстойно... поэтому мне нравится пока criteria

http://projects.spring.io/spring-data-rest/

один раз разобрался и написал, потом изи что-то добавляешь и переделываешь, даже если кардинально

мне вот эта концепция нравится, если применительно к java

тупо строишь read модель поверх твоего приложения под те UI которые нужны и не паришься

потому что если у тебя операции чтения и записи работают с одними и теми же структурами - ну такое... представление данных для чтения может сильно отличаться от того, что удобно для записи

если доводить до крайности - event sourcing

ну я также и делаю с гибером

тупо строишь read модель поверх твоего приложения под те UI которые нужны и не паришься

ну я также и делаю с гибером

но ты же сказал что будешь сущности пхать во вью а то json сгенерит