如何处理 Flex/Java Web 应用程序中的 M:M 实体关系？
我正在努力想出一种方法来有效管理 Flex 实体，这些实体在 JPA/Java 对应部分之间具有多对多关系。
问题是……想象一个具有两个实体的电影评论 Web 应用程序：
@Entity
Class Movie {
List<Viewer> Viewers;
}
@Entity
Class Viewer {
List<Movie> Movies;
}
这两个实体都可以彼此独立存在，并且彼此之间具有 1:M 关系。这种关系并不真正属于某一方或另一方。
在应用程序中，有一些 Flex UI 有时希望根据电影查看观众，而其他 UI 则希望根据观众查看电影。
目前，Movies.Viewers 和 Viewers.Movies 集合都是由 JPA 延迟加载的，效果很好。问题是，每次我向观众询问电影列表时，它们都会通过线路发送，然后在 Flex 中，我最终会得到一堆 Movie 对象（通常，并非总是）重复我已经拥有的对象那里。
这看起来效率很低，如果不处理重复的对象，可能会导致错误。
在我的实际应用程序中，我在一些非常大的对象图中存在大量此类关系。
在我看来，延迟加载的对象集合需要转变为急切加载的外键集合，这些外键用于显式加载 Flex 方面的对象。但这似乎是我在 Flex 中编写 JPA 提供程序！从不在 Flex 应用程序中存储状态的正确答案是？ （哎呀）救命！！
更新：
我应该补充一点，我的所有值对象都有一个在服务器端创建的 UID，因此我可以以某种方式使用它来查找/删除 Flex 端的重复项。但如何呢？
I am struggling to come up with a way to efficiently manage Flex entities that have a many-to-many relationships between their JPA/Java counter parts.
Here is the problem...imagine a movie review web application with two entities:
@Entity
Class Movie {
List<Viewer> Viewers;
}
@Entity
Class Viewer {
List<Movie> Movies;
}
Both of these entities can exist independently of each other and both have a 1:M relationship with the other. The relationship is not really owned by one side or the other.
Within the application there are Flex UI's that sometimes want to see viewers based on movies and other UI's that want to see movies based on viewers.
Currently both the Movies.Viewers and Viewers.Movies collections are lazy loaded by JPA which works fine. The problem is that every time I ask a viewer for it's list of movies, then they all get sent over the wire and then within Flex I end up with a bunch of Movie objects that (often, not always) duplicate the ones I already have there.
It seems inefficient at best and could likely cause errors if the duplicate objects are not dealt with.
In my real application I have tons of these types of relationships all over some very large object graphs.
It almost seems to me that the lazy loaded object collections need to be turned into eagerly loaded collections of foreign keys which are used to explicitly load objects on the Flex side of things. But this seems like I am writing a JPA provider in Flex! Is the correct answer to never store state in a Flex application? (Yikes) HELP!!
Update:
I should add that all my value objects have a UID that is created on the server side, so I could somehow use that to find/remove duplicates on the Flex side. But how?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于后端返回内存中已有的相同对象的新实例，您无能为力。尽管在搜索和过滤时，多个实例引用相同的实体（基于值，而不是内存位置）可能会导致一些意外的结果。这是因为两个不同实体上的简单 === 对于看似相同的实体并不总是正确，因为它们引用了内存中的 2 个不同对象。
我建议向您的实体添加自定义相等方法，而不是依赖 ===。对于实体，相等性将基于 id，这很可能也是数据库 id。对于值对象，相等性基于对象的状态。
另外，我不会尝试在客户端上保留太多状态。我知道这似乎是一个有吸引力的解决方案，并且它在一些 Flex 架构框架中得到推广，因为毕竟您正在构建一个富客户端，但根据我的经验，这会导致许多数据过时的情况并进一步导致问题沿着路。除非您正在使用托管数据（如在 LCDS 中），否则我更喜欢查询后端而不是使用客户端状态。
最后一点：在我看来，mm 关系是一个数据库实现细节，不应该翻译成客户端和服务器的领域。我更愿意创建由观众查询电影的服务方法，反之亦然。 Eric Evans 的 DDD 著作中有一些关于这个主题的好材料。
There is nothing you can do about the backend returning new instances of the same objects you already have in memory. Having multiple instances refering to the same entities (based on value, not memory location) can lead to some unexpected results though when searching and filtering. That is because a simple === on 2 different entities will not always be true on what seems to be the same entity because they refer to 2 different objects in memory.
I would suggest to add custom equality methods to your entities instead of relying on ===. In the case of entities, the equality will be based on the id, which is most likely also the database id. In case of value objects, equality is based on the state of the objects.
Also, I would not try to keep much state on the client. I know this seems like an attractive solution and that it is promoted in some of the Flex architetural frameworks, since after all you are building a rich client, but in my experience this leads to many scenarios where data is out of date and causes problems further down the road. Unless you are working with managed data (as in LCDS) I would prefer querying the backend instead of using the client state.
As a last note: the m-m relation is a database implementation detail in my opinion and should not be translated into the domain of both client and server. I would much rather create service methods that query the movies by a viewer or vice versa. There is some good material on this topic in the DDD writings of Eric Evans.
LCDS 试图通过使用数据管理来为您解决这个问题 - 但我不确定它是否仍在路线图上。所以，是的，通过使用直接方法（尝试使用客户端上的所有关系复制模型），假设您有无限的时间，您可能最终可以在 Flex 中编写自己的实体管理器。
就我而言，我使用的是 BlazeDS，并且我已经开始为客户端创建更简单的对象。例如，如果我需要所有电影，我将创建类似 MovieVO 传输对象的内容，然后从电影列表中创建对象列表。根据规范，我将在 MovieVO 中添加更多信息（例如计算观众数量的变量或简化的观众列表）。基本上我在客户端上简化了很多模型。缺点是我必须编写/修改大量粘合代码。
我很好奇听到其他方法，尤其是使用 weborb/graniteds 的开发人员。
LCDS tried to solve this problem for you, by using data management - however I'm not sure if it's still on the roadmap or not. So yes, by using the straight approach (trying to duplicate the model with all the relationships on the client) probably you could end by writing your own entity manager in Flex, assuming that you have an unlimited amount of time.
In my case I'm using BlazeDS and I've start creating simpler objects for the client. For example if I would need all the movies I would create something like a MovieVO transport object and I would create the list of the objects from the list of Movies. Depending on the specification I will add more information into the MovieVO (like a variable counting the number of viewers, or a simplified list of viewers). Basically I'm simplifying the model on the client a lot. The drawback is that I have to write/modify a lot of glue code.
I'm very curious to hear another approaches, especially from developers using weborb/graniteds.