Целостность объекта и кэширование в клиенте с состоянием

Question

Мне интересно, какие существуют стратегии для управления целостностью объектов в клиенте с состоянием, таком как приложение Flex или Silverlight.

Я имею в виду следующее: рассмотрим приложение, в котором у вас есть группа и субъект-участник. Группы содержат несколько участников, и участники могут принадлежать нескольким группам. В представлении перечислены различные группы, которые загружаются лениво (изначально нет участников). При запросе сведений о группе все участники загружаются и кэшируются, поэтому в следующий раз нам не потребуется вызывать службу для извлечения сведений и членов группы.

Теперь, когда мы запрашиваем сведения о другой группе, в которой уже есть тот же член группы, которая уже была загружена, мы будем беспокоиться о том, что этот член уже находится в памяти?

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

Какими-нибудь советами, идеями или опытом поделиться?

Answer 1

То, что вы описываете, - это то, что обычно решается с помощью «кэша первого уровня» (в Hibernate, «Session»; в JPA, «EntityManager»), который обеспечивает существование только одного экземпляра конкретной сущности в конкретный контекст. Как вы предполагаете, это можно применять к объектам, когда они выбираются с сервера, чтобы гарантировать, что все ссылки на конкретную сущность фактически являются ссылками на один и тот же экземпляр объекта. Вам также потребуется механизм, обеспечивающий существование сущностей, созданных внутри AVM, в том же контексте, чтобы к ним применялась похожая логика.

В проекте Granite Data Services есть проект под названием "Tide", целью которого является решение этой проблемы:

http://www.graniteds.org/confluence/display/DOC/6.+Tide+Data+Framework

Что касается DDD, важно не проектировать серверную часть как простой API доступа к данным, такой как простое предоставление набора DAO или репозиториев. Клиентскому приложению нельзя доверять, и на самом деле им очень легко манипулировать с помощью отладочного прокси-сервера, такого как Charles. Я всегда разрабатываю API сервисов, который адаптирован к пользовательскому интерфейсу (чтобы данные для экрана могли быть получены за один вызов) и имеет необходимую логику безопасности или проверки правильности, часто с использованием аннотаций и Spring AOP.

Answer 2

Что я хотел бы сделать, это создать службу приложений на стороне клиента, которая выполняет кэширование и обслуживание запросов данных. Это будет обрабатывать, существует ли объект в кэше. Если вы используете DDD, вам нужно решить, какой будет ваша совокупная корневая сущность. Группа или Участник. Вы не можете оба контролировать друг друга. Должен быть один пункт для управления загрузкой и т. Д. Посмотрите это видео об DDD в канадской ALT.NET OpenSpaces. http://altnetpedia.com/Calgary200808.ashx