Как обрабатывать отношения сущностей M: M в веб-приложении Flex / Java?

Question

Я изо всех сил пытаюсь найти способ эффективно управлять объектами Flex, которые имеют отношения многие ко многим между их счетными частями JPA / Java.

Вот проблема ... представьте себе веб-приложение для просмотра фильмов с двумя сущностями:

@Entity
Class Movie {
 List<Viewer> Viewers;
}

@Entity
Class Viewer {
 List<Movie> Movies;
}

Обе эти сущности могут существовать независимо друг от друга, и обе имеют отношение 1: M друг с другом.На самом деле отношения не принадлежат ни одной стороне, ни другой.

Внутри приложения есть пользовательские интерфейсы Flex, которые иногда хотят видеть зрителей на основе фильмов, и другие пользовательские интерфейсы, которые хотят видеть фильмы на основе зрителей.

В настоящее время обе коллекции Movies.Viewers и Viewers.Movies загружаются в JPA, что прекрасно работает.Проблема в том, что каждый раз, когда я спрашиваю у зрителя список фильмов, все они отправляются по проводам, а затем во Flex я получаю набор объектов Movie, которые (часто не всегда) дублируют те, что у меня уже есть.там.

В лучшем случае это кажется неэффективным и может привести к ошибкам, если с дублирующимися объектами не работать.

В моем реальном приложении у меня есть тонны таких типов отношений по всем очень большим графам объектов..

Мне почти кажется, что лениво загруженные коллекции объектов нужно превратить в активно загруженные коллекции внешних ключей, которые используются для явной загрузки объектов на стороне Flex.Но похоже, что я пишу провайдеру JPA во Flex!Является ли правильный ответ никогда не сохранять состояние в приложении Flex?(Yikes) HELP !!

Обновление:

Я должен добавить, что все мои объекты-значения имеют UID, который создается на стороне сервера, поэтому я мог как-то использоватьчто найти / удалить дубликаты на стороне Flex.Но как?

Answer 1

Вы ничего не можете сделать с бэкендом, возвращающим новые экземпляры тех же объектов, которые у вас уже есть в памяти. Наличие нескольких экземпляров, ссылающихся на одни и те же объекты (в зависимости от значения, а не от места в памяти), может привести к неожиданным результатам при поиске и фильтрации. Это связано с тем, что простое === для двух разных объектов не всегда будет верно для того, что кажется одним и тем же объектом, поскольку они ссылаются на два разных объекта в памяти.

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

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

Как последнее замечание: отношение m-m, на мой взгляд, является деталью реализации базы данных и не должно переводиться в домен как клиента, так и сервера. Я бы предпочел создать сервисные методы, которые запрашивают фильмы у зрителя или наоборот. Есть несколько хороших материалов на эту тему в работах Эрика Эванса по DDD.

Answer 2

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

В моем случае я использую BlazeDS и начинаю создавать более простые объекты для клиента. Например, если мне понадобятся все фильмы, я бы создал что-то вроде транспортного объекта MovieVO и создал бы список объектов из списка фильмов. В зависимости от спецификации я добавлю больше информации в MovieVO (например, переменную, подсчитывающую количество зрителей, или упрощенный список зрителей). По сути, я сильно упрощаю модель на клиенте. Недостатком является то, что я должен написать / изменить много кода клея.

Мне очень любопытно услышать другие подходы, особенно от разработчиков, использующих weborb / graniteds.