我是 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 才真正开始
使发展达到如此程度
更好的？ 通过什么方式？
I'm new to Flex development, and RIAs in general. I've got a CRUD-style Java + Spring + Hibernate service on top of which I'm writing a Flex UI. Currently I'm using BlazeDS. This is an internal application running on a local network.
It's become apparent to me that the way RIAs work is more similar to a desktop application than a web application in that we load up the entire model and work with it directly on the client (or at least the portion that we're interested in). This doesn't really jive well with BlazeDS because really it only supports remoting and not data management, thus it can become a lot of extra work to make sure that clients are in sync and to avoid reloading the model which can be large (especially since lazy loading is not possible).
So it feels like what I'm left with is a situation where I have to treat my Flex application more like a regular old web application where I do a lot of fine grained loading of data.
LiveCycle is too expensive. The free version of WebOrb for Java really only does remoting.
Enter GraniteDS. As far as I can determine, it's the only free solution out there that has many of the data management features of LiveCycle. I've started to go through its documentation a bit and suddenly feel like it's yet another quagmire of framework that I'll have to learn just to get an application running.
So my question(s) to the StackOverflow audience is:
1) do you recommend GraniteDS,
especially if my current Java stack
is Spring + Hibernate?
2) at what point do you feel like it starts to
pay off? That is, at what level of
application complexity do you feel
that using GraniteDS really starts
to make development that much
better? In what ways?
发布评论
评论（5）
如果您致力于 Spring 并且不想引入 Seam，那么我认为 Granite DS 不会为您提供比 Blaze DS 更大的功能。 有一个有用的实用程序，可以确保在任何时候客户端中仅存在任何一个实体的单个实例，但实际上，通过使用弱引用的几个字典实例以及应用于服务器调用的一些后处理，可以很容易地做到这一点。 许多其他功能都是 Seam 特定的，正如文档中提到的：
http://www.graniteds.org/confluence/display/DOC/6.+Tide+Data+Framework
不过，我确实认为 Granite 的数据管理方法比 Livecycle 有了很大的改进，因为它们确实有很大不同。 来自花岗岩文档：
这与 Livecycle DS 使用“托管集合”的方式不同，在“托管集合”中，您调用 fill() 来获取大量数据，然后调用 commit() 方法来批量保存更改。 这将后端视为原始数据访问 API，并且当您有细粒度的安全要求时，它会开始变得复杂（或完全崩溃）。 因此我认为 Granite 的方法更可行。
If you're committed to Spring and don't want to introduce Seam then I don't think that Granite DS will give you much beyond Blaze DS. There is a useful utility that ensures only a single instance of any one entity exists in the client at any one time but it's actually pretty easy to do that with a few instances of Dictionary with weak references and some post-processing applied to the server calls. A lot of the other features are Seam-specific as alluded to here in the docs:
http://www.graniteds.org/confluence/display/DOC/6.+Tide+Data+Framework
I do however think that Granite's approach to data management is a big improvement over Livecycle's because they are indeed quite different. From the Granite docs:
This is different to how Livecycle DS uses "managed collections" where you invoke fill() to grab large swathes of data and then invoke commit() methods to persist changes en-mass. This treats the backend like a raw data access API and starts to get complicated (or simply fall apart entirely) when you have fine-grained security requirements. Therefore I think Granite's approach is far more workable.
所有数据管理功能（JPA 分离实体的序列化、客户端实体缓存、数据分页...）都可与 Spring 配合使用。
GraniteDS 不强制执行任何操作，如果您想在服务器上使用 Seam，则只需要 Seam。
All data management features (serialization of JPA detached entities, client entity caching, data paging...) work with Spring.
GraniteDS does not mandate anything, you only need Seam if you want to use Seam on the server.
实际上，Java 版 WebORB 的免费版本确实可以进行数据管理。 我最近发布了 WebORB for Java、LiveCycle DS、BlazeDS 和 GraniteDS 之间的比较。 您可以在此处查看此比较图表：http://bit.ly/d7RVnJ 我对您的产品感兴趣评论和反馈，因为我们希望这是网络上最全面的功能比较。
干杯，
凯瑟琳
Actually, the free version of WebORB for Java does do data management. I've recently posted a comparison between WebORB for Java, LiveCycle DS, BlazeDS and GraniteDS. You can view this comparison chart here: http://bit.ly/d7RVnJ I'd be interested in your comments and feedback as we want this to be the most comprehensive feature comparison on the web.
Cheers,
Kathleen
您看过 spring-blazeDS 集成项目吗？
Have you looked at the spring-blazeDS integration project?
GraniteDS 与 Seam Framework、Hibernate 和 MySql 是一个非常好的组合。 我所做的是创建数据库，使用seamgen 生成休眠实体，然后从那里开始工作。
GraniteDS with Seam Framework, Hibernate and MySql is a very nice combination. What I do is create the database, use seamgen to generate hibernate entities then work from there.