Flex - 保持客户端数据与后端数据库同步的最佳策略？
在使用 BlazeDS AMF 远程处理的 Adobe Flex 应用程序中，保持本地数据最新并与后端数据库同步的最佳策略是什么？
在典型的 Web 应用程序中，网页每次加载时都会刷新视图，因此视图中的数据永远不会太旧。
在 Flex 应用程序中，存在预先加载更多数据以在选项卡、面板等之间共享的诱惑。这些数据通常从后端刷新的频率较低，因此更有可能过时 - 导致保存时出现问题等。
那么，克服这个问题的最佳方法是什么？
A。 像构建 Web 应用程序一样构建 Flex 应用程序 - 在每次可能的视图更改时重新加载后端数据
b． 忽略该问题，只在发生过时数据问题时对其进行处理（冒着惹恼更有可能使用过时数据的用户的风险）
c． 就
我而言，通过 LiveCycle RTMP 保持数据通道打开不是一种选择。
In an Adobe flex applicaiton using BlazeDS AMF remoting, what is the best stategy for keeping the local data fresh and in synch with the backend database?
In a typical web application, web pages refresh the view each time they are loaded, so the data in the view is never too old.
In a Flex application, there is the tempation to load more data up-front to be shared across tabs, panels, etc. This data is typically refreshed from the backend less often, so there is a greater chance of it being stale - leading to problems when saving, etc.
So, what's the best way to overcome this problem?
a. build the Flex application as if it was a web app - reload the backend data on every possible view change
b. ignore the problem and just deal with stale data issues when they occur (at the risk of annoying users who are more likely to be working with stale data)
c. something else
In my case, keeping the data channel open via LiveCycle RTMP is not an option.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
过去我选择了“a”。 如果您使用远程对象，您可以设置一些缓存样式的逻辑，以使它们在远程端保持同步。
山姆
In the past I have gone with choice "a". If you were using Remote Objects you could setup some cache-style logic to keep them in sync on the remote end.
Sam
您不需要 Livecycle 和 RTMP 来拥有通知机制，您可以使用 BlazeDS 的通道并使用流/长轮询策略来实现
You don't need Livecycle and RTMP in order to have a notification mechanism, you can do it with the channels from BlazeDS and use a streaming/long polling strategy
如果您无法在 BlazeDS 中使用消息传递协议，那么我必须同意您应该通过 HTTP 进行 RTMP 轮询。 在 AMF 中使用 RTMP 时，数据会被压缩，这有助于加快速度，因此客户端在更新之间需要等待很长时间。 如果产品的客户决定支付额外的硬件和许可证费用，这还允许您稍后扩展到推送方法。
If you can't use the messaging protocol in BlazeDS, then I would have to agree that you should do RTMP polling over HTTP. The data is compressed when using RTMP in AMF which helps speed things up so the client is waiting long between updates. This would also allow you to later scale up to the push methods if the product's customer decides to pay up for the extra hardware and licenses.
A。 考虑通过执行自己的通知或轮询的代理来优化后端更改：它知道是否有任何数据是脏的，如果不是，将快速返回（如 304）。
b. 通常，用户看的次数多于触摸的次数。 考虑在查找时进行一级刷新，在开始并继续编辑时考虑另一级刷新。
看看 BuzzWord：它会锁定编辑，但也会频繁自动保存和解锁。
干杯
a. Consider optimizing back-end changes through a proxy that does its own notification or poling: it knows if any of the data is dirty, and will quick-return (a la a 304) if not.
b. Often, users look more than they touch. Consider one level of refresh for looking and another when they start and continue to edit.
Look at BuzzWord: it locks on edit, but also automatically saves and unlocks frequently.
Cheers
不能使用 RTMP over HTTP（HTTP 轮询）吗？
这样您仍然可以使用 RTMP，尽管它比真正的 RTMP 慢得多，但您仍然可以通过这种方式广播更新。
我们有一个应用程序，它使用 RTMP 通过简单地广播包含表/主键对的 RTMP 消息来发出插入、更新和删除信号，让应用程序自动更新其数据。 我们使用 RTMP 通过 Http 来完成此操作。
Can't you use RTMP over HTTP (HTTP Polling)?
That way you can still use RTMP, and although it is much slower than real RTMP you can still braodcast updates this way.
We have an app that uses RTMP to signal inserts, updates and deletes by simply broadcasting RTMP messages containing the Table/PrimaryKey pair, leaving the app to automatically update it's data. We do this over Http using RTMP.
我发现这篇关于同步的文章：
http:// /www.databasejournal.com/features/sybase/article.php/3769756/The-Missing-Sync.htm
它没有讨论技术细节，但您可以猜测哪种编码将实现此策略。
我也没有来自服务器的精美通知，因此我需要同步策略。
例如，我的 modelLocator 中有一个公司列表。 它不会经常更改，它不够大，无法考虑分页，我不想在每个用户操作上重新加载全部内容（removeAll（）），但我不希望我的应用程序崩溃或更新损坏的数据如果它已从应用程序的另一个实例中更新或删除。
我现在所做的是将 SELECT 日期时间保存在会话中。 当我回来刷新数据时，我选择 WHERE last_modified>$SESSION['lastLoad']
这样我在加载数据后只得到修改的行（大多数时候是 0 行）。
显然，您需要在每次插入和更新时更新last_modified。
对于 DELETE 来说就更棘手了。 正如该人在他的文章中指出的那样：
“我们怎样才能发送不再存在的记录”
你需要告诉flex应该删除哪个项目（比如通过ID），这样你就不能真正在DELETE上删除:)
当用户删除一家公司时，你会执行更新：deleted =1
然后在刷新公司时，对于已删除 = 1 的行，您只需将 ID 发送回 Flex，以确保该公司不再位于模型中。
最后但并非最不重要的一点是，您需要编写一个函数来清理已删除=1且last_modified早于... 3天或您认为适合您需要的任何行。
好处是，如果用户错误地删除了一行，它仍然在数据库中，并且您可以在 3 天内将其从真正的删除中保存下来。
I found this article about synchronization:
http://www.databasejournal.com/features/sybase/article.php/3769756/The-Missing-Sync.htm
It doesn't go into technical details but you can guess what kind of coding will implement this strategies.
I also don't have fancy notifications from my server so I need synchronization strategies.
For instance I have a list of companies in my modelLocator. It doesn't change really often, it's not big enough to consider pagination, I don't want to reload it all (removeAll()) on each user action but yet I don't want my application to crash or UPDATE corrupt data in case it has been UPDATED or DELETED from another instance of the application.
What I do now is saving in a SESSION the SELECT datetime. When I come back for refreshing the data I SELECT WHERE last_modified>$SESSION['lastLoad']
This way I get only rows modified after I loaded the data (most of the time 0 rows).
Obviously you need to UPDATE last_modified on each INSERT and UPDATE.
For DELETE it's more tricky. As the guy point out in his article:
"How can we send up a record that no longer exists"
You need to tell flex which item it should delete (say by ID) so you cannot really DELETE on DELETE :)
When a user delete a company you do an UPDATE instead: deleted=1
Then on refresh companies, for row where deleted=1 you just send back the ID to flex so that it makes sure this company isn't in the model anymore.
Last but not the least, you need to write a function that clean rows where deleted=1 and last_modified is older than ... 3days or whatever you think suits your needs.
The good thing is that if a user delete a row by mistake it's still in the database and you can save it from real delete within 3days.
与其在 Flex 客户端上进行缓存，为什么不在服务器端进行缓存呢？ 一些原因，
1）当你在服务器端缓存数据时，它是集中的，你可以确保所有客户端都具有相同的数据状态
2）服务器端有比Flex更好的缓存选项。 您还可以有一个 cron 作业，它根据某个频率（例如每 24 小时）刷新一次数据。
3）由于数据缓存在服务器上，不需要每次都从数据库中获取数据，与flex的通信会快得多
。
泰哈斯
Rather than caching on flex client, why not do caching on server side? Some reasons,
1) When you cache data on server side, its centralized and you can make sure all clients have the same state of data
2) There are much better options available on server side for caching rather than on flex. Also you can have a cron job which refreshes data based on some frequency say every 24 hours.
3) As data is cached on server and it doesn't need to fetch it from db every time, communication with flex will be much faster
Regards,
Tejas