|
Java форум JavaTalks
форум программистов
|
|
|
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
pjotar : 453
Бывалый
Откуда: Санкт-Петербург
|
 Май 09, 2010 9:55 |
 |
|
Передаю @Entity клиенту(апплету) по RMI. В jar клиента приходиться класть всякие IndirectList.class, DatabaseQuery.class вообщем часть реализации JPA.
Правильно ли я догадываюсь, что с @Entity классом нужно сделать что-то перед тем, как передавать? |
|
|
|
 |
i_home : 10
Новичок
|
| Май 11, 2010 2:07 |
| |
|
Как вариант перенести аннотации в orm.xml, оставив в проекте только plain классы.
Я в таких случаях всегда так делаю. |
|
|
|
|
pjotar : 453
Бывалый
Откуда: Санкт-Петербург
|
| Дек 26, 2011 11:20 |
| |
|
Спасибо, ещё пара вопросов:
1. JPA провайдер занимается кодогенерацией, подсовывет изменённые Entity-классы? Например, какие-нибудь прокси?
2. Метод EntityManager.detach(entity) может помоч? Нужно ли делать detach перед передачей по RMI? |
|
|
|
|
i_home : 10
Новичок
|
| Дек 26, 2011 20:43 |
| |
|
Коротко - нет,
и от зависимостей это не избавит.
Вообще detach для другого, он нужен чтобы объект не синхронизировал изменеия с базой, тоесть при изменении detached бина в managed контексте, по завершении транзакции изменения просто не будут занесены в базу.
А вот при получении модифицированных бинов с клиентской строны, для того чтобы сохранить именения в базе, перед персистом их нажо мерджить.
Примерно так. |
|
|
|
|
Skipy : 4801
Я тут живу!
Откуда: Москва, Россия
|
| Дек 27, 2011 10:19 |
| |
|
| pjotar писал(а): |
Спасибо, ещё пара вопросов:
1. JPA провайдер занимается кодогенерацией, подсовывет изменённые Entity-классы? Например, какие-нибудь прокси?
2. Метод EntityManager.detach(entity) может помоч? Нужно ли делать detach перед передачей по RMI? |
Есть Data Access Object (DAO), а есть Data Transfer Object (DTO). Вот DTO как раз и нужны, чтобы передавать данные без учета всех связей с ORM. Как правило, DTO формируется на основе DAO с передачей через конструктор. Обратно - либо getDAO возвращает новый DAO-объект, либо updateDAO обновляет существующий DAO.
Да, разумеется, DAO и DTO не обязаны быть один в один.
_________________
С уважением,
Евгений aka Skipy
www.skipy.ru
P.S. Я НЕ решаю задачи ЗА других! |
|
|
|
|
Shogun : 67
Новичок
|
| Дек 27, 2011 19:53 |
| |
|
| Skipy писал(а): |
Есть Data Access Object (DAO), а есть Data Transfer Object (DTO). Вот DTO как раз и нужны, чтобы передавать данные без учета всех связей с ORM. Как правило, DTO формируется на основе DAO с передачей через конструктор. Обратно - либо getDAO возвращает новый DAO-объект, либо updateDAO обновляет существующий DAO.
Да, разумеется, DAO и DTO не обязаны быть один в один. |
DTO - паттерн, который должен использоваться как можно реже. Сейчас его можно увидеть на очень старых проектах, в которых используется EJB 2.0. Порой доводилось видеть манию использования этого паттерна в проектах, где половина разработчиков так и не вкусила прелестей EJB 3.0 и JPA.
Думаю, что вполне нормально передавать Entity(главное не забыть пометить ее как сериализуемую), и detach произойдет в любом случае: или при завершении транзакции, или перед передачей по RMI. |
|
|
|
|
nullvoid : 505
Постоянный посетитель
Откуда: Красноярск
|
| Дек 28, 2011 7:33 |
| |
|
| Shogun писал(а): |
| Skipy писал(а): |
Есть Data Access Object (DAO), а есть Data Transfer Object (DTO). Вот DTO как раз и нужны, чтобы передавать данные без учета всех связей с ORM. Как правило, DTO формируется на основе DAO с передачей через конструктор. Обратно - либо getDAO возвращает новый DAO-объект, либо updateDAO обновляет существующий DAO.
Да, разумеется, DAO и DTO не обязаны быть один в один. |
DTO - паттерн, который должен использоваться как можно реже. Сейчас его можно увидеть на очень старых проектах, в которых используется EJB 2.0. Порой доводилось видеть манию использования этого паттерна в проектах, где половина разработчиков так и не вкусила прелестей EJB 3.0 и JPA.
Думаю, что вполне нормально передавать Entity(главное не забыть пометить ее как сериализуемую), и detach произойдет в любом случае: или при завершении транзакции, или перед передачей по RMI. |
А если dto не соответствует один в один сущности, что тогда прикажете делать?
_________________
http://LinguaLeo.ru/r/8b3o08 |
|
|
|
|
Shogun : 67
Новичок
|
| Дек 28, 2011 16:47 |
| |
|
| nullvoid писал(а): |
| Shogun писал(а): |
| Skipy писал(а): |
Есть Data Access Object (DAO), а есть Data Transfer Object (DTO). Вот DTO как раз и нужны, чтобы передавать данные без учета всех связей с ORM. Как правило, DTO формируется на основе DAO с передачей через конструктор. Обратно - либо getDAO возвращает новый DAO-объект, либо updateDAO обновляет существующий DAO.
Да, разумеется, DAO и DTO не обязаны быть один в один. |
DTO - паттерн, который должен использоваться как можно реже. Сейчас его можно увидеть на очень старых проектах, в которых используется EJB 2.0. Порой доводилось видеть манию использования этого паттерна в проектах, где половина разработчиков так и не вкусила прелестей EJB 3.0 и JPA.
Думаю, что вполне нормально передавать Entity(главное не забыть пометить ее как сериализуемую), и detach произойдет в любом случае: или при завершении транзакции, или перед передачей по RMI. |
А если dto не соответствует один в один сущности, что тогда прикажете делать? |
Если случаи единичные, то это как раз те случаи, где DTO может быть применен как решение, но я предпочитаю использовать Adapter'ы(Завернуть одну или несколько entity, c подсчетом, добавлений полей и т.п. Это отдельная тема, для нее можно и отдельный топик создать). Если же DTO применяется очень часто - пересмотрите дизайн и архитектуру(разумеется, я не имею ввиду проекты, где используется EJB 2.0). |
|
|
|
|
Mam(O)n : 61
Новичок
|
| Дек 29, 2011 0:49 |
| |
|
| pjotar писал(а): |
Спасибо, ещё пара вопросов:
1. JPA провайдер занимается кодогенерацией, подсовывет изменённые Entity-классы?
|
Как раз недавно напоролся на то, что eclipselink производит модифицированные объекты (google: eclipselink weaving), добавляя дополнительные поля, хранящие информацию о ленивых отношениях и изменениях, произошедших в объекте. Но в моём случае была CORBA и вместо того, чтоб ругаться я получал на удалённой стороне объекты с непроинициализированными полями. Как тут себя поведёт RMI я затрудняюсь сказать. В моём случае нужно было на клиенте иметь идентично изменённые объекты, которые можно получить используя специального агента или произведя т.н. static weaving на этапе сборки проекта. |
|
|
|
|
|
|
|
