Привет всем.
У меня есть система, которая коллектит данные о выполнение тестов и генерит отчеты по ним.
Данные о выполнение тестов приходят в REST сервис, тот в свою очередь дергает DAO.
Проблема возникла, что приходится писать много кода для обмена данными между слоями.
Сейчас это работает так:
Клиент делает PUT XML данных в REST, с помощью JAXB данные мапятся на объекты.
Далее REST сервис должен конвертировать JAXB объекты в DTO объекты, о которых знает DAO.
То есть для одной сущности я должен создать JAXB объект, DTO, и конвертер в обе стороны.
Код выходит достаточно громоздким. вообщем-то 50% работы это мапинг объектов туда-сюда.
Возможно ли это упростить, сделать, как-то подругому? Как вы обычно решаете этот вопрос?
Здравствуйте, Fry33, Вы писали:
F>Возможно ли это упростить, сделать, как-то подругому? Как вы обычно решаете этот вопрос?
Почему именно XML? Использование DTO можно свести к минимуму. DTO создаю, только если с помошью него нужно агрегировать сущности. Во всех остальных случаях испольщую сущности.
Серализация в Json через Jackson. RCP/REST через Spring MVC. DAO на Hibernate ORM. Везде одни и теже сущности. Нужно только продумать стратегию разрешения ленивых зависимостей до сериализации.
Re[2]: web tier <-> data tier как правильно обениваться данн
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Fry33, Вы писали:
F>>Возможно ли это упростить, сделать, как-то подругому? Как вы обычно решаете этот вопрос? B>Почему именно XML? Использование DTO можно свести к минимуму. DTO создаю, только если с помошью него нужно агрегировать сущности. Во всех остальных случаях испольщую сущности. B>Серализация в Json через Jackson. RCP/REST через Spring MVC. DAO на Hibernate ORM. Везде одни и теже сущности. Нужно только продумать стратегию разрешения ленивых зависимостей до сериализации.
REST построен на Jersey, данные должны передоваться как через XML так и через JSON. Без какого-либо ORM, всё ручками, поскольку используем NoSQL.
То есть, если я правильно вас понял, надо объядинить entity REST слоя и entity Data слоя?
Наверное на данном этапе это еще возможно, но насколько это может аукнуться вдальнейшем?
Если REST будет усложняться и сущности возвращаемые им не будут иметь аналогов сущностей в Data layout'те?
Например появятся отчеты или особая группировка entity на уровне REST?
Re[3]: web tier <-> data tier как правильно обениваться данн
Здравствуйте, Fry33, Вы писали:
F>Например появятся отчеты или особая группировка entity на уровне REST?
Не знаю как там в NoSQL отчеты делаеются. Но в SQL данные отчета это список сущностей.
На счет группировки написал уже — для этого создаются DTO. Отказ от DTO тоже имеет свои грабли. Например на сервере есть ассоциация, а на клиенте она вообще не нужна. Убрать её нельзя. Можно только null значение передать.
Как альтернативу можнете посмотреть Dozer (http://dozer.sourceforge.net/). Чтобы конвертировать DTO в сущности и обратно. Но это имеет смысл только в том случае, если у вас клиентская модель, действительно, сильно отличается от серверной.
Re[4]: web tier <-> data tier как правильно обениваться данн
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Fry33, Вы писали:
F>>Например появятся отчеты или особая группировка entity на уровне REST? B>Не знаю как там в NoSQL отчеты делаеются. Но в SQL данные отчета это список сущностей. B>На счет группировки написал уже — для этого создаются DTO. Отказ от DTO тоже имеет свои грабли. Например на сервере есть ассоциация, а на клиенте она вообще не нужна. Убрать её нельзя. Можно только null значение передать.
B>Как альтернативу можнете посмотреть Dozer (http://dozer.sourceforge.net/). Чтобы конвертировать DTO в сущности и обратно. Но это имеет смысл только в том случае, если у вас клиентская модель, действительно, сильно отличается от серверной.
То есть если делать всё "по правилам", то нужно разделять модели дата и сервис лейаута. А на деле, просто надо оценить, насколько они различные и постараться слить, скажем в один entity пакет, чтобы избежать overhead с поддержкой двух одинаковых моделей и конвертеров. Правильно я понял посыл ваших сообщений?
Re[5]: web tier <-> data tier как правильно обениваться данн
Здравствуйте, Fry33, Вы писали:
F>То есть если делать всё "по правилам", то нужно разделять модели дата и сервис лейаута. А на деле, просто надо оценить, насколько они различные и постараться слить, скажем в один entity пакет, чтобы избежать overhead с поддержкой двух одинаковых моделей и конвертеров. Правильно я понял посыл ваших сообщений?
Да.
