|
|
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Всем привет. Есть множество ентити на сервере. Есть клиенты(ios, android), которые запрашивают данные этих энтити. Вопрос: как лучше организовать трансфер данных с сервера на клиентские приложения? Вариантов как я понимаю несколько: передавать энтити напрямую, но как тогда клиентское приложение(ios например) сможет распарсить какое-то специфическое поле, например DateTime time (joda). Или что если помимо полей конкретной энтити нужно передать еще что-то. Ставить в соответствие каждой энтити некий объект, в котором будут находится все поля сущности + все остальное чего душа пожелает(дата в long например, что удобно как для андроид так и для ios), т.е. как бы приходим к паттерну DTO о котором слышала массу негативных отзывов. Как решаются подобные задачи? Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2015, 18:10 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Почитай про Jersey. Обьекты передаются в формате JSON а потом на клиенте/сервере преобразуются назад в объект. Единственный минус что нужно на клиенте и сервере одинаковые классы передаваемых объектов. Можешь почитать про RMI, CORBA. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2015, 18:22 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
z3r9Почитай про Jersey. Обьекты передаются в формате JSON а потом на клиенте/сервере преобразуются назад в объект. Единственный минус что нужно на клиенте и сервере одинаковые классы передаваемых объектов. Можешь почитать про RMI, CORBA. Сейчас у меня это работает через spring mvc + jackson, json-ами и обмениваюсь. Айос парсит полученный json, на андроид клиенте из json-а автоматом строится java класс. Мне не очень нравится при каждом добавлении нового поля в энтити, лезть в трансфер-модель, которая соответствует этой энтити, и так же добавлять поле. Поддерживать весь этот огород с сотнями энтити мучительно больно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2015, 18:32 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Хочется услышать еще какие-то мнения по моему вопросу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2015, 19:03 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2015, 20:47 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
JulT, можно сделать модуль мавен для транзакционных объектов. И просто собираешь этот модуль и потом просто в другом проекте он автоматом подгружается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2015, 21:15 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
JulTХочется услышать еще какие-то мнения по моему вопросу непонятно, зачем тебе объекты на клиенте? На каком этапе нужны Java классы? http://habrahabr.ru/post/260317/ AFAIK там свой DataSet вроде есть для связи с БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2015, 21:20 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
а зачем вам дто тут? Почему не генерироватьjson из BO? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2015, 21:31 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Petro123JulTХочется услышать еще какие-то мнения по моему вопросу непонятно, зачем тебе объекты на клиенте? На каком этапе нужны Java классы? http://habrahabr.ru/post/260317/ AFAIK там свой DataSet вроде есть для связи с БД. Ну вот андроид приложение, например, для конвертации джсона в класс использует следующее: ObjectMapper mapper = new ObjectMapper(); User user = mapper.readValue(http path... User.class); Соответственно, андроид клиент должен знать класс, в то время как User является энтити, хотя если я правильно понимаю при передаче этой энтити все аннотации (@Table, @Column и т.д.) игнорируются. А если мне хочется передать на клиента не просто DateTime time из класса User, а time в формате long? В таком случае моя энтити User уже не подходит и нужно прибегать к dto и уже там крутить, вертеть как мне хочется. Можно конечно transient поля использовать, но как-не не нравится мне эта идея. В чем я заблуждаюсь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2015, 20:34 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
забыл ника зачем вам дто тут? Почему не генерироватьjson из BO? Простите, ВО это что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2015, 20:35 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
JulTВ чем я заблуждаюсь? ты так и не объяснил, зачем тебе класс. Всё равно биндить к визуальному контролу надо будет не класс. А логика вся на сервере, иначе на клиенте тогда нужно делать свою модель данных. ВО тоже самое что DTO - голимые данные и больше ничего. IMHO уж лучше JSON\REST Какая разница в чём будет дата приходить? Ты ни слова не сказал о ГУИ для даты. А ведь у тебя клиент. Возможно со смещением по таймзоне. ....... Т.е. проектируешь Окно с гридом. Значит передаёшь с сервера данные именно для него. И в формате именно для него. Зачем тебе ОРМ в андроиде я не понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2015, 22:01 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
JulT, не нужно никаких классов генерировать, делайте HashMap и ArrayList <HashMap> и никакого гемороя не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2015, 09:15 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Petro123ВО тоже самое что DTO - голимые данные и больше ничего. . Это не так. Business Object это и есть ваша Entity, то бишь User. Все ваши проблемы как-то надуманы, dto тут ни к селу ни к городу. Кастомизировать выхлоп json - разве это проблема? Вариантов масса, все зависит от технологии коих миилиард. XStream, Gson, Spring MVC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2015, 11:19 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
забыл никPetro123ВО тоже самое что DTO - голимые данные и больше ничего. . Это не так. Business Object это и есть ваша Entity, то бишь User. Все ваши проблемы как-то надуманы, dto тут ни к селу ни к городу. Кастомизировать выхлоп json - разве это проблема? Вариантов масса, все зависит от технологии коих миилиард. XStream, Gson, Spring MVC я спутал с Values Obj - VO )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2015, 12:08 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
забыл никPetro123ВО тоже самое что DTO - голимые данные и больше ничего. . Это не так. Business Object это и есть ваша Entity, то бишь User. Все ваши проблемы как-то надуманы, dto тут ни к селу ни к городу. Кастомизировать выхлоп json - разве это проблема? Вариантов масса, все зависит от технологии коих миилиард. XStream, Gson, Spring MVC Я по-другому спрошу. Вот есть в моем проекте(Spring mvc+Hibernate и т.д., под андроид я не пишу) код, что-то типа: @Entity User ..... @Column String name Для каждой такой BO создается некий UserDetails, который полностью включает в себя все поля из User + еще что-то. Именно этот UserDetails и отправляется в ввиде json-a используя Spring mvc в клиентское приложение. Андроид клиент хранит у себя класс UserDetails и когда к нему прилетает json с сервера он формирует из него (при помощи jackson) объект UserDetails. Зачем автор этого кода сделал прослойку в виде UserDetails, почему сразу не передает User? На сколько я поняла это делалось для того чтобы удобно было передавать любые другие поля помимо тех, которые хранит в себе User. Т.е., например мне помимо имени пользователя нужно передать кол-во заказов этого пользователя. Поля orderCount в User нет и в базе оно не хранится, поэтому либо добавляем его с аннотацие @transient в User и перед отправкой заполняем, либо берем UserDetails, добавляем в него orderCount и отправляем UserDetails. Мне просто очень хочется убрать всю эту груду дополнительных классов на каждый мой BO, но не уверена стоит ли это делать т.к. может быть здесь заложен глубокий и правильный смысл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2015, 19:26 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
JulTзабыл никпропущено... Это не так. Business Object это и есть ваша Entity, то бишь User. Все ваши проблемы как-то надуманы, dto тут ни к селу ни к городу. Кастомизировать выхлоп json - разве это проблема? Вариантов масса, все зависит от технологии коих миилиард. XStream, Gson, Spring MVC Я по-другому спрошу. Вот есть в моем проекте(Spring mvc+Hibernate и т.д., под андроид я не пишу) код, что-то типа: @Entity User ..... @Column String name Для каждой такой BO создается некий UserDetails, который полностью включает в себя все поля из User + еще что-то. Именно этот UserDetails и отправляется в ввиде json-a используя Spring mvc в клиентское приложение. Андроид клиент хранит у себя класс UserDetails и когда к нему прилетает json с сервера он формирует из него (при помощи jackson) объект UserDetails. Зачем автор этого кода сделал прослойку в виде UserDetails, почему сразу не передает User? На сколько я поняла это делалось для того чтобы удобно было передавать любые другие поля помимо тех, которые хранит в себе User. Т.е., например мне помимо имени пользователя нужно передать кол-во заказов этого пользователя. Поля orderCount в User нет и в базе оно не хранится, поэтому либо добавляем его с аннотацие @transient в User и перед отправкой заполняем, либо берем UserDetails, добавляем в него orderCount и отправляем UserDetails. Мне просто очень хочется убрать всю эту груду дополнительных классов на каждый мой BO, но не уверена стоит ли это делать т.к. может быть здесь заложен глубокий и правильный смысл причин может быть много, зависит от ситуации может просто потому что сделали. может из за того что details было ну очень много то разделили на User и UserDetails, и поэтому чтобы каждый раз доставать из БД User может повлиять на производительность, в то время как нам нужно всеголи проверить логин пароль узнать чтобы пускать или нет User куда либо либо. может UserDetails это не entity а просто обертка (без кода непонятно). Что удобно тк в этом случае "случайно" запороть entity User не получится если случайно сессия все еще открыта или в открытой сессиии User передается еще либо куда. знающие люди могут дополнить этот список и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 09:56 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
JulT, Для того чтобы менять архитектуру проекта, нужно быть очень опытным. Решать только вам. Класс над классом или "впаре") то же самое что вьюхи в бд и JOIN. Вы сказали что клиента не пишите, тогда и сабж не имеет смысла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 11:01 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
JulTЯ по-другому спрошу. Вот есть в моем проекте(Spring mvc+Hibernate и т.д., под андроид я не пишу) код, что-то типа: @Entity User ..... @Column String name Для каждой такой BO создается некий UserDetails, который полностью включает в себя все поля из User + еще что-то. Именно этот UserDetails и отправляется в ввиде json-a используя Spring mvc в клиентское приложение. Андроид клиент хранит у себя класс UserDetails и когда к нему прилетает json с сервера он формирует из него (при помощи jackson) объект UserDetails. Зачем автор этого кода сделал прослойку в виде UserDetails, почему сразу не передает User? На сколько я поняла это делалось для того чтобы удобно было передавать любые другие поля помимо тех, которые хранит в себе User. Т.е., например мне помимо имени пользователя нужно передать кол-во заказов этого пользователя. Поля orderCount в User нет и в базе оно не хранится, поэтому либо добавляем его с аннотацие @transient в User и перед отправкой заполняем, либо берем UserDetails, добавляем в него orderCount и отправляем UserDetails. Мне просто очень хочется убрать всю эту груду дополнительных классов на каждый мой BO, но не уверена стоит ли это делать т.к. может быть здесь заложен глубокий и правильный смысл А ну в таком случае промежуточный слой скорее всего нужен. По факту у вас есть BusinessObject User, который занимает определенное место в domain model с определенным количеством атрибутов и операций. Клиенту же нужно его специфическое представление, которое для разных клиентов теоретически может быть и разным, в таком случае введение промежуточного слоя в виде DTO зачастую оправдано. К тому же делать business object частью публичного API тоже не самая лучшая идея. Если же клиент мейнтейнится одними и теми же людьми, что и сервер, и дрягих клиентов не предполагается, чтобы уменьшить сложность, слой DTO иногда выкидывают, зависит от ситуации, общих советов тут быть не может. В целом я не вижу большой проблемы в перекладывании User в UserDetails, если там большинство полей одинаковые, в конце концов есть такая штука как Dozer. UserDetails ud = entityMapper.map(user, UserDetails.class); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 12:12 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Вопрос : а как вы создаете DTO объекты в spring ? используя spring data ? https://rmannibucau.wordpress.com/2013/11/20/deltaspike-data-repositories-with-dtos/ через Mapper ? Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 16:23 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Atum1, ParameterizedRowMapper для JdbcTemplate а для spring data Repository ? что то уже есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 16:57 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
JulTЯ по-другому спрошу. Вот есть в моем проекте(Spring mvc+Hibernate и т.д., под андроид я не пишу) код, что-то типа: @Entity User ..... @Column String name Для каждой такой BO создается некий UserDetails, который полностью включает в себя все поля из User + еще что-то. Именно этот UserDetails и отправляется в ввиде json-a используя Spring mvc в клиентское приложение. Андроид клиент хранит у себя класс UserDetails и когда к нему прилетает json с сервера он формирует из него (при помощи jackson) объект UserDetails. Зачем автор этого кода сделал прослойку в виде UserDetails, почему сразу не передает User? На сколько я поняла это делалось для того чтобы удобно было передавать любые другие поля помимо тех, которые хранит в себе User. Т.е., например мне помимо имени пользователя нужно передать кол-во заказов этого пользователя. Поля orderCount в User нет и в базе оно не хранится, поэтому либо добавляем его с аннотацие @transient в User и перед отправкой заполняем, либо берем UserDetails, добавляем в него orderCount и отправляем UserDetails. Мне просто очень хочется убрать всю эту груду дополнительных классов на каждый мой BO, но не уверена стоит ли это делать т.к. может быть здесь заложен глубокий и правильный смысл Добавлю свои 5 копеек. User может быть замешан в разных непохожих друг на друга бизнес-операциях. И могут быть созданы несколько сервисов, которые будут возвращать данные о пользователе относительно какой-то операции. По каждой такой операции могут быть необходимы свои уникальные сведения о пользователе. Здесь пригодятся DTO. Под каждую операцию свой, чтобы не смешивать и, читая код, сразу понимать, какие сведения должны передаваться. Если в коде сервиса дописывать что-то к json вручную, то это совсем не удобочитаемо. Вот как-то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 18:20 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Еще допишу. В DTO могут быть поля, значения, которых не просто вытаскиваются из какого-то поля в БД, а вычисляются по мере необходимости. Таких полей может не быть в классе доменной модели. В DTO может передаваться дополнительная информация, непосредственно к объекту не относящаяся. Например, с товаром - список похожих товаров. Это к вопросу об использовании DTO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 19:17 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
yelenaЕсли в коде сервиса дописывать что-то к json вручную, то это совсем не удобочитаемо. Вот как-то так. imho В вебе очень много значит Url - универсальный указатель ресурса. Если не мешать всё в кучу (все сервисы). /<URL‐путь>?<параметры>#<якорь> если принять <URL‐путь> как ИмяФункции\ИмяСервиса, то можно спокойно передать на клиента JSON. Или даже строку. Не нужны тут ни DTO ни объекты)). Они нужны в толстом клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 19:29 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Petro123yelenaЕсли в коде сервиса дописывать что-то к json вручную, то это совсем не удобочитаемо. Вот как-то так. imho В вебе очень много значит Url - универсальный указатель ресурса. Если не мешать всё в кучу (все сервисы). /<URL‐путь>?<параметры>#<якорь> если принять <URL‐путь> как ИмяФункции\ИмяСервиса, то можно спокойно передать на клиента JSON. Или даже строку. Не нужны тут ни DTO ни объекты)). Они нужны в толстом клиенте. Клиенту можно передать и JSON, и XML. И тут все равно, толстый он или тонкий. Я говорю о том, что если выставляется какой-то сервис, то к нему есть требования: что он должен передавать. И что сначала эти требования можно представить в виде DTO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 19:52 |
|
||
|
Как правильно передать данные с сервера на клиента
|
|||
|---|---|---|---|
|
#18+
Petro123, можно и по-простому для тонкого клиента. Только как бы потом при такой простоте в сложном проекте не заблудиться. А еще один и тот же сервис можно использовать и для тонкого, и для толстого клиента. Вам такой вариант в голову не приходил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 19:56 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=39014331&tid=2125110]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 239ms |
| total: | 467ms |

| 0 / 0 |
