Сторона клиента, кэширующаяся в GWT
У нас есть gwt-клиент, который получает довольно много данных из наших серверов. Логически, я хочу кэшировать данные по стороне клиента, спасая сервер от ненужных запросов.
На сегодняшний день я позволил ему до своих моделей для обработки кэширования данных, которые не масштабируются очень хорошо. Это также стало проблемой, так как различные разработчики в нашей команде разрабатывают свою собственную функциональность "кэширования", которая лавинно рассылает проект с дублированиями.
Я думаю о том, как можно было реализовать "единственную точку входа", которая обрабатывает все кэширование, оставляя модели невежественными о том, как кэширование обрабатывается.
У кого-либо есть опыт со стороной клиента, кэширующейся в GWT? Существует ли стандартный подход, который может быть реализован?
5 ответов
Я предлагаю вам рассмотреть gwt-presenter и CachingDispatchAsync . Он обеспечивает единую точку входа для выполнения удаленных команд и, следовательно, прекрасную возможность для кэширования.
В недавней записи в блоге описывается возможный подход.
Возможно, вы захотите взглянуть на Command Pattern; Рэй Райан провел в Google IO доклад о передовых методах работы с GWT, вот стенограмма: http://extgwt-mvp4g-gae.blogspot.com/2009/10/gwt-app-architecture-best-practices. html
Он предлагает использовать шаблон команды с использованием объектов Action и Response / Result, которые вводятся и выводятся прокси-сервером службы. Это отличные объекты для инкапсуляции любого кэширования, которое вы хотите выполнить на клиенте.
Вот отрывок: «У меня есть отличная денежная единица для реализации политик кеширования. Может быть, всякий раз, когда я вижу один и тот же запрос GET дважды, я кэширую ответ, который получил в прошлый раз, и просто возвращаю его себе. немедленно. Не беспокойтесь о поездках на стороне сервера »
. В довольно большом проекте я выбрал другое направление. Я разработал объект DtoCache, который по сути содержал ссылку на каждый AsyncCallback, который ожидал ответа от вызова службы в очереди ожидания. После того, как DtoCache получил объекты с сервера, они были кэшированы внутри DtoCache. Кэшированный результат отныне возвращался всем поставленным в очередь и вновь созданным AsyncCallbacks для одного и того же вызова службы.
Для уже готового, очень сложного механизма кэширования для CRUD-операций рассмотрите Smart GWT. Этот пример демонстрирует возможность адаптивного выполнения операций на стороне клиента (когда кэш позволяет это), при этом поддерживая пейджинг для больших наборов данных:
http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category
Это поведение раскрывается через класс ResultSet, если вам нужно разместить собственные виджеты поверх него:
http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/data/ResultSet.html
Я подумал, что Itemscript - это что-то вроде аккуратности. Это RESTful JSON база данных, которая работает как на клиенте (GWT), так и на сервере.
Проверьте это!
-JP
Существует два уровня кэширования:
- Кэширование в течение одной сессии браузера.
- Кэширование между сессиями браузера, например, кэшированные данные должны быть доступны после перезапуска браузера.
Что кэшировать: зависит от вашего приложения, вы можете захотеть кэшировать
- Защищенные данные для конкретного пользователя
- Публичные статические (или полустатические, например, редко изменяемые) данные
Как кэшировать:
- Для первого уровня кэширования мы можем использовать код GWT, предложенный в ответах, или написать свой собственный.
- Для второго мы должны использовать возможности кэширования браузера. Стандартный подход заключается в размещении данных в html (будь то статические html-файлы или динамические, генерируемые, например, jsp/сервлетом). Затем ваше приложение использует http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsOverlay.html методы для получения данных.