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

не понимаю что за геттеры) ну в смысле, доступ к данным объекта? getId...

не понимаю что за геттеры) ну в смысле, доступ к данным объекта? getId...

да, нет доступа

или что?)

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

да, нет доступа

а зачем тогда они вообще нужны такие?))

а зачем тогда они вообще нужны такие?))

кто "они"?

сущности

сущности без геттеров?)

угу

или у тебя исключительно сеттеры?)

ну вот... мы чуть раньше обсуждали что "объект" это такая штука, которая хранит данные и их обрабатывает. А вместо того что бы гонять данные между объектами мы шлем сообщения "сделай то-то то-то"

> или у тебя исключительно сеттеры?) нет ни сеттеров (привычных в духе setSomething) ни геттеров

есть методы с поведением

ООП же

класс тупо из геттеров и сеттеров - это как структура данных.

это не объект

там нет инкапсуляции

я ооп то не знаю, пишу процедуры в классы обернутые, пришел к вам, научится)

а ну вот тип того

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

вообще

например если тебе надо получить id сущности вместо getId() ты пишешь toId()

метод который сконвертирует объект в другую хрень - ее айдишник

угу

другая семантика, хотя по коду будет казаться что одно и то же

у тебя будет toJson

это один из вариантов как не делать геттеры)

и честно - я им пользуюсь

только toArray а не toJson

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

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

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

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

а если тебе надо в 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 (аннотации хоть и являются мета информацией - это все же смешение ответственности)