Фреймворки взаимодействия и взаимодействия между клиентом и сервером - PullRequest
Новая
       21

Фреймворки взаимодействия и взаимодействия между клиентом и сервером

3 голосов
/ 05 апреля 2010

При использовании сред постоянства, таких как Hibernate, JPA и т. Д. На стороне сервера, каковы общие методы передачи данных между клиентом и сервером? Существуют ли какие-либо шаблоны дизайна для того же самого?

Спасибо.

Ответы [ 4 ]

1 голос
/ 06 апреля 2010

Я не знаю о шаблонах, но я знаю, что в дизайне, использующем, например, EJB3 с JPA, не рекомендуется передавать сущности JPA клиенту через удаленные EJB, поскольку прокси остаются и могут генерировать много бесполезного сетевого трафика. Вам лучше отделить ваши сущности или предоставить клиенту простые объекты-значения.

1 голос
/ 06 апреля 2010

Клиент-сервер, или с включением базы данных, 3-уровневая архитектура сама по себе является шаблоном проектирования. Вопрос скорее в том, какие технологии следует использовать в коммуникации. Есть много вариантов, например, HTTP, TCP, UDP, JMS, XMLRPC, RMI, CORBA, C RPC или флэш-накопители, переносимые почтовыми голубями. В общем, рекомендуется

  • используйте технологию, которая имеет инструментарий для определения формата вашего сообщения / данных, например SOAP (WSDL), CORBA (IDL), XML (XSD, Relax NG, Schematron, ..) через JMS / HTTP / ....
  • выберите текстовый формат (XML, JSON, ..) вместо двоичного (RMI, CORBA, ..), если производительность не является серьезной проблемой. Текстовые форматы легче понять программистам, пишущим следующую версию, или новому клиенту. Также легче отлаживать или проверять такой интерфейс.
  • используйте открытую стандартную технологию, не изобретайте колесо заново.
  • выберите базовый транспорт, соответствующий вашей модели связи. Например. JMS хорошо подходит для связи «забыл и забыл», а HTTP хорошо подходит для синхронного запроса-ответа.
  • Имейте в виду архитектуру более высокого уровня. Например. если ваш сервер (сервис) является одним из многих, обслуживаемых одним и тем же ИТ-отделом, рекомендуется использовать одну и ту же коммуникационную технологию для всех из них (см. также SOA).

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

0 голосов
/ 30 мая 2014

Как сказал Себастьен Лорбер вы можете использовать шаблон DTO, то есть копировать объекты в POJO. Но вы можете отправлять объекты JPA клиенту, чтобы избежать DTO. Есть две проблемы с отправкой сущностей:

  1. Ленивые отношения: вы должны инициализировать все необходимые ленивые отношения, прежде чем отправлять сущности. (Есть несколько решений, как удаленный клиент может читать ленивые отношения, я бы не рекомендовал это).
  2. Объекты могут содержать специальный код JPA / Hibernate - аннотации, коллекции, прокси. Вы должны либо
    • Добавление банок Hibernate / JPA в код клиента.
    • Очистите сущности, прежде чем отправлять их. (Вы не очищаете аннотации, просто добавьте hibernate-annotations.jar в код клиента). См. Hibernate, убирайся от моего POJO!
0 голосов
/ 06 апреля 2010

В идеале уровень постоянства должен быть совершенно отдельным от уровня связи клиент-сервер. Идея здесь не является строго закономерной: слабая связь .

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

...