我正在努力想出一种方法 有效地 管理在JPA / Java计数器部件之间具有多对多关系的Flex实体。
问题出在这里......想象一下有两个实体的电影评论网页应用程序：
@Entity
Class Movie {
List<Viewer> Viewers;
}
@Entity
Class Viewer {
List<Movie> Movies;
}
这两个实体可以彼此独立存在，并且两者之间具有1：M的关系。这种关系并非真正由一方或另一方所有。
在应用程序中有Flex UI，有时希望看到基于电影和其他想要根据观众观看电影的UI的观众。
目前，JPA延迟加载Movies.Viewers和Viewers.Movies个集合，工作正常。问题在于，每当我向观众询问它的电影列表时，它们都会通过网络发送，然后在Flex中我最终得到一堆电影对象（通常并不总是）复制我已经拥有的对象那里。
充其量效率似乎很低，如果不处理重复的对象，可能会导致错误。
在我的实际应用程序中，我在一些非常大的对象图上都有大量这些类型的关系。
在我看来，延迟加载的对象集合需要转换为急切加载的外键集合，这些外键用于在Flex方面显式加载对象。但这似乎是我在Flex中编写JPA提供程序！从不在Flex应用程序中存储状态是正确的答案吗？ （哎呀）帮助!!
更新
我应该补充一点，我的所有值对象都有一个在服务器端创建的UID，所以我可以用它来查找/删除Flex端的重复项。但是如何？
答案 0 :(得分：2)
关于后端返回内存中已有的相同对象的新实例，您无能为力。有多个实例引用相同的实体（基于值，而不是内存位置），但在搜索和过滤时会导致一些意外的结果。这是因为在两个不同的实体上的简单===并不总是在同一实体上是真的，因为它们在内存中引用了两个不同的对象。
我建议为您的实体添加自定义相等方法，而不是依赖于===。在实体的情况下，相等性将基于id，其很可能也是数据库id。在值对象的情况下，相等性基于对象的状态。
另外，我不会试图在客户端保持很多状态。我知道这似乎是一个有吸引力的解决方案，并且它在一些Flex架构框架中得到了提升，因为毕竟你正在构建一个富客户端，但根据我的经验，这会导致许多场景，数据过时并导致问题进一步发生在路上。除非您使用托管数据（如在LCDS中），否则我更愿意查询后端而不是使用客户端状态。
作为最后一点：在我看来，m-m关系是一个数据库实现细节，不应该被翻译成客户端和服务器的域。我宁愿创建服务方法来查看观众的电影，反之亦然。在Eric Evans的DDD着作中，有一些关于这个主题的好材料。
答案 1 :(得分：1)
LCDS试图通过使用数据管理为您解决这个问题 - 但是我不确定它是否仍然在路线图上。所以，是的，通过使用直接方法（尝试使用客户端上的所有关系复制模型），您可以通过在Flex中编写自己的实体管理器来结束，假设您有无限的时间。
在我的情况下，我正在使用BlazeDS，我开始为客户端创建更简单的对象。例如，如果我需要所有电影，我会创建类似MovieVO传输对象的东西，我会从电影列表中创建对象列表。根据规范，我将在MovieVO中添加更多信息（如计算观看者数量的变量或简化的观看者列表）。基本上我在客户端上简化了很多模型。缺点是我必须编写/修改很多胶水代码。
我很想知道另一种方法，特别是使用weborb / graniteds的开发人员。