Объекты передачи данных и методы транзакционного обслуживания

Question

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

Я думаю, что две популярные альтернативы DTO и причины, по которым они мне не нравятся:

1. Открыть шаблон сеанса в представлении. Это мне не нравится, так как я хотел бы, чтобы сервисные методы были действительно транзакционными (то есть сеанс Hibernate фиксируется и закрывается при выходе из метода). Это связано главным образом с тем, что мне не нужно беспокоиться о транзакциях, если мне, например, позже понадобится опубликовать сервис как веб-сервис.

2. Передача доменных / бизнес-объектов через сервисные методы вместо DTO и получение необходимых атрибутов / свойств. Это несколько лучше. Однако в нетривиальной иерархии объектов домена со сложными отношениями сущностей стремящаяся выборка должна где-то остановиться. И когда это произойдет, я не вижу, как это не очень быстро превратится в полный взлом, заменив сущности ссылочными идентификаторами повсюду.

Я что-то упустил или DTO фактически единственный надежный подход с точки зрения ремонтопригодности?

Answer 1

Репозитории, Сервисы и Контроллеры должны быть местами, имеющими отношение к ядру вашего приложения (Hibernate Session, безусловно, может быть использован как весь уровень вашего репозитория, если хотите).

Представления не должны иметь дело с ядром вашего приложения, моделью домена. Они должны иметь дело не с живыми объектами, а с неживым, индивидуальным представлением живых объектов. Предполагается, что представлениям передаются только те данные, которые им нужны, в определенном формате, в котором они нуждаются. Вы должны создать DTO для ваших взглядов. Этот шаблон также известен как модель представления, в отличие от модели предметной области.

Чтобы сделать вашу жизнь проще, могут существовать библиотеки или платформы, которые могут автоматически сопоставлять объекты модели вашего домена с объектами модели представления и обратно. В .NET в настоящее время разрабатывается платформа с открытым исходным кодом под названием AutoMapper; Я не уверен, что есть для Java.

Answer 2

Единственный способ по-настоящему использовать объекты от начала до конца - это использовать что-то более сложное, чем OpenSessionInView. По моему опыту, вам придется управлять сеансом гибернации вручную на уровне приложений. OpenSessionInView предоставит вам один и тот же сеанс только для одного запроса. После этого вам нужно будет постоянно подключаться к текущей сессии. Взгляните на Seam и разговоры, или внедрите свое собственное управление Hibernate Session. В настоящее время мы вручную управляем нашими сеансами в зависимости от того, когда запускается и заканчивается мастер, и используем Spring AOP для своевременного присоединения сеансов к нужным потокам (сеансы не являются потоко-безопасными, не очень хорошо сочетаются с AJAX)

WebServices, с другой стороны, наверняка будут нуждаться в некоторой форме DTO. Я не вижу способа обойти это. Объекты могут выглядеть как POJO, но на самом деле это не так, их сериализация может варьироваться от трудной до почти невозможной. Просто создайте DTO, которые соответствуют цели метода обслуживания, и покончите с этим.

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

Answer 3

Мне нравится идея DTO, но я всегда чувствовал, что другие разработчики их не очень хорошо принимали или не любили, поскольку для правильной реализации этого подхода вплоть до базы данных обычно требуется много усилий. Вот почему я создал Blaze-Persistence Entity Views , которые позволяют вам моделировать DTO как интерфейсы, которые эффективно сопоставляются с моделью сущностей JPA. Вы можете применить представление сущности к запросу, и запрос будет адаптирован таким образом, что он будет получать только фактически требуемое состояние, а не все состояние и отображать его в Java.

Используя представления сущностей, вам не нужно открывать сеанс в представлении анти-паттерна, потому что желаемая структура загружается с нетерпением. Поскольку объекты сущности не задействованы, также не возникнет проблем с отложенной загрузкой.

Поскольку сущностная модель часто очень похожа на модель DTO на ранних стадиях разработки, я часто вижу, как разработчики просто пропускают создание отдельной модели DTO, пытаясь избежать хлопот. Как только сквозные проблемы, такие как аудит, статистика или денормализация, попадают в модель сущности или объем данных в модели сущности становится намного больше, чем то, что вам действительно нужно для сценариев использования сущности, у разработчиков возникают проблемы.

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

Answer 4

Если вы ослабите свое требование закрыть сеанс, вы все равно сможете использовать открытый сеанс в поле зрения и просто зафиксировать все в своих транзакциях службы. Сеанс все еще будет доступен для отложенной загрузки, но все ваши транзакции будут завершены. Но если вы собираетесь переключиться на веб-сервис, вам все равно придется загружать все свои объекты. DTO просто заставляют вас сознательно вызывать нагрузку и предотвращают случайную лень.

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