и как-то могу получить спиок объеков User

hql выглядит уровня select id,name from Employee..

пока правда List возвращает не List<user>, а List<object>

хотя походу эт не так(

это пробовал?

https://docs.jboss.org/hibernate/orm/3.5/api/org/hibernate/criterion/PropertyProjection.html

Как-то давно задавался тем же вопросом

это пробовал?

угу сейчас пробую

просто меня дико раздражает

но не помню как делал.

огромное количество таких запросов

когда из всех полей мне от силы нужно 2-3

welcome to orm

да знаю я, что это orm

просто на 5 или 6 год юзания orm

я решил это оптимизировать))

для этого и юзают querydsl

http://www.querydsl.com/

Это все хорошо, но уже есть хибер

он работает поверх хибернейта

воу, не знал этого

пойду сча читать об этом

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

либо на левые классы

Что почитать за проектирование бд на бэкэнде?

Domain

нормально ли иметь раздельные DTO для запросов и ответов?

зависит от твоей бизнес-задачи

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

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

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

тогда не парься, делай раздельными

а как их обзывать тогда? сейчас есть просто OrderDto, но если создать отдельную DTOшку для создания сущности, называть ее как-то типа CreateOrderDto?

ага

Ну че, ты в епам прошел?

не, не прошел

к ейчару вызывали?

неа, по тесту отсеяли

тупой :с

будешь еще пробовать? вроже в феврале будет новый набор

если закончу текущий проект, то буду. а так времени нет все равно

а как их обзывать тогда? сейчас есть просто OrderDto, но если создать отдельную DTOшку для создания сущности, называть ее как-то типа CreateOrderDto?

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

Порты?) Или файловые дескрипторы?)

Ну конкретно порты, дескриптеров ты можешь хоть 100к сделать, а вот портов для подключений в протоколе 16bit unsigned вроде как

Конкретно можно сделать виртуальные интерфейсы, вхерачить несколько сетевух, но когда ты это делаешь нужно как бы понимать нахуя и что будет за этим всем.

Domain

Прости?

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

типа абстрактный OrderDto, а от него CreateOrderDto и RecieveOrderDto?

типа абстрактный OrderDto, а от него CreateOrderDto и RecieveOrderDto?

ага

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

у меня так например из базы могут достаться объекты замапиться в какой-нибудь класс под эгидой одного абстрактного

типа абстрактный OrderDto, а от него CreateOrderDto и RecieveOrderDto?

можно двумя классами обойтись

без абстрактного

Прости?

Domain model pattern

можно двумя классами обойтись

а почему?

а почему?

чтобы не плодить лишних сущностей

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

ну если одна сущность имеет поля, а вторая поля первой + свои

то зачем выделять абстракт?)

ну если так, то будет лучше даже от одной другую заэкстендить

я про это и говорю)

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

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

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

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

да, спасибо, буду думать

Возвращать сущности @Entity вместо использования DTO - это нормальная практика?

Возвращать сущности @Entity вместо использования DTO - это нормальная практика?

обычно - нет

В классе DTO доллжен быть конструктор, который принимает entity объект?

ERROR: S client not available

Чтобы скопировать все нужные поля

как вариант

или отдельный класс, паттерн маппер

с методами переливашками

обычно - нет

Ну мне вобщем тоже не очень нравится Entity как DTO. Хотя этот проект поощряет это: https://github.com/FasterXML/jackson-datatype-hibernate

Он паралельно с библиотекой Jackson лежит

я пользовался ей

и опять же, там вроде как расширение для маппера джексоновского, ты по сути ObjectNode возвращаешь,а не доменный объект напрямую

HibernateAwareObjectMapper

Могу возвращать доменный объект, а Jackson уже сериализирует его и отправляет клиенту

если конвертер настроишь

Да. А конвертер автоматически настраивается. Я говорю про случай, когда метод контроллера возвращает доменный объект (или ResponseEntity<?>) и аннотирован @ResponseBody

я понял, про что ты

но автоматически не настраивается

надо прописать бин в конвертере

пока правда List возвращает не List<user>, а List<object>

Можно создать вторую DTO и воспользоваться new в hql-запросе. Недостаток - на каждый запрос, где требуются лишь некоторые поля, придётся клепать новый класс.

Народ, подскажите, можно ли с Gradle'ом сделать нечто такое: Есть проект с модулями: root, A, B, C. Модуль A зависит от B, а B от C, т. е. A -> B -> C Я хочу, чтобы модуль A не знал о C и его зависимостях. Пытался указывать зависимости с compile(project(...)) {transitive = false} , но тогда проект компилился, а вот модуля C и его зависимостей в jar'ке не оказывается. Кто-нибудь знает, возможно ли добиться того, чего я пытаюсь сделать или нет?

Народ, подскажите, можно ли с Gradle'ом сделать нечто такое: Есть проект с модулями: root, A, B, C. Модуль A зависит от B, а B от C, т. е. A -> B -> C Я хочу, чтобы модуль A не знал о C и его зависимостях. Пытался указывать зависимости с compile(project(...)) {transitive = false} , но тогда проект компилился, а вот модуля C и его зависимостей в jar'ке не оказывается. Кто-нибудь знает, возможно ли добиться того, чего я пытаюсь сделать или нет?

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

Есть кто сертификацию oracle проходил?

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

Ясно, спасибо. Странно, что решение мне нагуглить не удалось. Либо искать не умею. Придётся забить пока. Интересно, неужели всех устраивает возможность вызывать DAO слой из контроллеров, например?)

а как иначе? дублировать вызовы в сервисном слое?

Народ, подскажите, можно ли с Gradle'ом сделать нечто такое: Есть проект с модулями: root, A, B, C. Модуль A зависит от B, а B от C, т. е. A -> B -> C Я хочу, чтобы модуль A не знал о C и его зависимостях. Пытался указывать зависимости с compile(project(...)) {transitive = false} , но тогда проект компилился, а вот модуля C и его зависимостей в jar'ке не оказывается. Кто-нибудь знает, возможно ли добиться того, чего я пытаюсь сделать или нет?

даже по логике то, что ты говоришь вызывает противоречие)

а зависит от б, которое зависит от с

ессно, а будет зависеть от с)

>Интересно, неужели всех устраивает возможность вызывать DAO слой из контроллеров, например?) изолируется это все в сервисе

а как иначе? дублировать вызовы в сервисном слое?

Ну как-то странно из контроллеров деркать персистент слой. spring-data-rest не в счет, это скорее костыль чем решение. На этапе контроллеров у тебя же есть только реквест, соответственно ты с него достаешь всё что тебу нужно и шлешь в сервис, который уже решает что с ним делать.

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

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

Тоже долго не мог понять этого, вроде бы mvc, но при этом не mvc)

В итоге забил, считая это просто кастрированным mvc, который просто более удобен для инженеров)

ессно, а будет зависеть от с)

У градла зависимости можно делать нетранзитивными. И я надеялся, что это как раз на видимость влияет, а не на то, что из результирующей jar'ки будут выпелены все подзависимости проекта.

а ты толстую джарку собираешь или как?

>Интересно, неужели всех устраивает возможность вызывать DAO слой из контроллеров, например?) изолируется это все в сервисе

Но я могу потенциально дёрнуть dao в контроллере.