我应该投资 GraniteDS 进行 Flex + Java 开发吗？答案

【问题标题】：Should I invest in GraniteDS for Flex + Java development?我应该投资 GraniteDS 进行 Flex + Java 开发吗？
【发布时间】：2010-11-02 13:00:51
【问题描述】：

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

对我来说很明显，RIA 的工作方式更类似于桌面应用程序而不是 Web 应用程序，因为我们加载整个模型并直接在客户端上使用它（或者至少是我们正在使用的部分）有兴趣）。这对于 BlazeDS 来说并不是很好，因为它实际上只支持远程处理而不是数据管理，因此确保客户端同步并避免重新加载可能很大的模型可能会成为很多额外的工作（尤其是因为延迟加载是不可能的）。

因此，我觉得我不得不将我的 Flex 应用程序更像是一个常规的旧 Web 应用程序，在其中我执行大量细粒度的数据加载。

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

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

所以我对 StackOverflow 观众的问题是：

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

2) 你觉得它从什么时候开始清偿？也就是说，在什么级别你觉得应用程序的复杂性真正开始使用 GraniteDS 使发展如此之多更好的？以什么方式？

【问题讨论】：

您知道有免费版本的实时循环数据服务吗？ adobe.com/products/livecycle/dataservices/faq.html
许可证非常严格...一个 CPU。
我面临着完全相同的问题，这到底是在哪里结束的？
@HDAve - 不幸的是，我放弃了整个想法并坚持使用常规网络应用程序。这些“替代实物”项目对我来说不值得麻烦/冒险。
常规网络应用程序是指“html/javascript/ajax”而不是 Flex 吗？您还在使用 Flex...但是使用常规的 RemoteObject（或 SOAP 或 REST）Web 方法吗？如果是这样，这就是我倾向于......自己处理数据而不是使用花哨的数据管理模块。不过，我仍然使用 Flex/Blaze……因为我认为它还有许多其他好处。

标签： java apache-flex blazeds livecycle graniteds

【解决方案1】：

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

干杯，凯瑟琳

【讨论】：

【解决方案2】：

GraniteDS 与 Seam 框架、Hibernate 和 MySql 是一个非常好的组合。我所做的是创建数据库，使用 seamgen 生成休眠实体，然后从那里开始工作。

【讨论】：

【解决方案3】：

您看过spring-blazeDS 集成项目吗？

【讨论】：

当然，我正在使用它。我的问题是关于 GraniteDS，因为它可能会填补 BlazeDS 的一些缺失功能（例如数据管理）。

【解决方案4】：

所有数据管理功能（JPA 分离实体的序列化、客户端实体缓存、数据分页...）都可以使用 Spring。 GraniteDS 不强制要求任何东西，如果你想在服务器上使用 Seam，你只需要 Seam。

【讨论】：

【解决方案5】：

如果您致力于 Spring 并且不想引入 Seam，那么我认为 Granite DS 不会为您提供比 Blaze DS 更多的功能。有一个有用的实用程序可以确保任何时候在客户端中只存在任何一个实体的单个实例，但实际上很容易做到这一点，只需几个带有弱引用的 Dictionary 实例和一些应用于服务器调用的后处理.正如文档中提到的，许多其他功能都是 Seam 特定的：

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

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

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

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

这与 Livecycle DS 使用“托管集合”的方式不同，您在其中调用 fill() 来获取大量数据，然后调用 commit() 方法来保持整体更改。这将后端视为原始数据访问 API，当您有细粒度的安全要求时，它开始变得复杂（或完全崩溃）。因此，我认为 Granite 的方法更可行。

【讨论】：

数据管理是我最感兴趣的功能。从文档中我不清楚 - 这是一个仅适用于 Seam 的功能吗？