为了Flex + Java开发，我应该投资于GraniteDS吗？

Question

我是Flex开发和RIA的新手。我有一个CRUD风格的Java + Spring + Hibernate服务，在上面我正在编写一个Flex。目前我正在使用BlazeDS。这是在本地网络上运行的内部应用程序。

在我看来，RIA的工作方式更类似于桌面应用程序，而不是web应用程序，因为我们加载整个模型并直接在客户端(或者至少是我们感兴趣的部分)使用它。这并不适合BlazeDS，因为它只支持远程处理，而不支持数据管理，因此需要做大量额外工作，以确保客户端同步，并避免重新加载可能很大的模型(特别是因为不可能进行延迟加载)。

因此，我觉得剩下的是我必须把我的Flex应用程序当作一个常规的老web应用程序，在那里我要做很多细粒度的数据加载。

LiveCycle太贵了。WebOrb for Java的免费版本实际上只执行远程处理。

输入GraniteDS。据我所知，这是唯一一个具有LiveCycle的许多数据管理功能的免费解决方案。我已经开始阅读它的文档，突然觉得这是另一个框架泥潭，我必须学习它才能运行一个应用程序。

因此，我对StackOverflow观众的问题是：

1)您推荐GraniteDS吗，特别是如果我当前的Java堆栈是Spring +Hibernate的话？

2)在什么时候你觉得它开始有回报了？也就是说，在应用程序复杂性的哪个层次上，您认为使用GraniteDS确实可以使开发变得更好？以什么方式？

Answer 1

如果你致力于春天，不想介绍Seam，那么我认为Granite DS不会给你带来更多的火焰DS。有一个有用的实用工具，它可以确保任何一个实体的一个实例在任何时候都存在于客户端中，但是实际上很容易使用几个带有弱引用的字典实例和应用于服务器调用的一些后置处理。许多其他特性都是Seam特定的，如文档中所提到的：

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

通常，Tide方法是尽量减少在客户机和服务器之间工作所需的代码量。它的原理与JBoss Seam的原理非常相似，这也是Tide第一次集成使用这个框架的主要原因。与Spring和EJB 3的集成也是可用的，但有一些限制。

不过，我确实认为Granite的数据管理方法与Livecycle相比有很大的改进，因为它们确实有很大的不同。来自花岗岩的文档：

所有客户机/服务器交互都是通过对服务器公开的服务进行方法调用来完成的，因此尊重远程服务定义的事务边界和安全性。

这与Livecycle使用“托管集合”的方式不同，在这种情况下，您调用fill()获取大量数据，然后调用commit()方法来持久化更改。这将后端视为原始数据访问API，当您有细粒度的安全需求时，它开始变得复杂(或完全崩溃)。因此，我认为花岗岩的方法更可行。

Answer 2

所有数据管理功能( JPA分离实体的序列化、客户端实体缓存、数据分页.)和Spring一起工作。GraniteDS不强制执行任何操作，只需要在服务器上使用Seam时才需要Seam。

Answer 3

实际上，WebORB for Java的免费版本确实进行数据管理。我最近发布了WebORB for Java、LiveCycle DS、BlazeDS和GraniteDS之间的比较。您可以在这里查看此比较图表：http://bit.ly/d7RVnJ，我会对您的评论和反馈感兴趣，因为我们希望这是web上最全面的功能比较。

干杯，凯瑟琳