Когда отложенная загрузка становится проблемой в RIA?

Question

Итак, у меня есть простое веб-приложение, использующее Spring MVC + Hibernate, и я использую OpenSessionInViewFilter. Недавно я думал о замене пользовательского интерфейса на что-то вроде Flex или GWT.

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

Итак, допустим, у меня есть метод для возврата Клиента, и у Клиента есть группа Контактов, и у Контактов есть группа Адресов и так далее. Если я вызову getCustomer () из моего нового контроллера «RIA», он получит Заказчика, но коллекция Контактов Заказчика будет просто прокси или нулевой.

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

Любой совет?

Answer 1

Вы абсолютно правы, что это создает проблему для RIA. Если вы используете OpenSessionInViewFilter, то данные не будут возвращаться с нулевым значением; скорее, сериализатор будет обходить весь граф объектов и отправлять огромное количество данных обратно. Это приведет к серьезным проблемам с производительностью.

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

Другой подход состоит в том, чтобы представить слой непосредственно перед сериализатором, который подготавливает ваш граф объектов для сериализации. Один из подходов, который мы использовали в некоторых прошлых проектах, заключался в том, чтобы ввести аспект уровня обслуживания, который будет обходить весь граф объектов и заменять ленивые прокси новым экземпляром Entity только с его установленным свойством @Id. Если график будет сохранен позже, это обеспечит непреднамеренное обнуление отношений @ManyToOne. Вы можете вызвать getter или использовать Hibernate.initialize () для принудительной инициализации данных, которые вы хотите отправить по сети. Это становится более сложным, когда вы вводите каскадное сохранение отношений @OneToMany или @ManyToMany в Hibernate.

Недавно я наткнулся на солютин по имени Галаад, который предназначен для решения этой проблемы. Он использует подход, аналогичный описанному выше:

http://noon.gilead.free.fr/gilead/

Я также считаю, что Granite DS имеет решение этой проблемы в рамках своей платформы Tide:

http://www.graniteds.org/confluence/display/DOC/4.+Lazy+Initialization

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

Answer 2

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

Тебе не нужно беспокоиться.