立即保存数据，关闭，保存按钮？在这种情况下哪个更好
在我的 GWT 应用程序中，每当用户进行更改时，我都会立即将用户所做的所有操作保存到后台的数据存储中。到目前为止，这一切都很好，因为用户可以更改的内容并没有发生太大变化。
但现在我添加了一系列用户可以检查和查看的复选框。取消选中：
每次将所有内容立即保存到数据库是否合适用户选中/取消选中某个框？我想到的是减少我的 Web 应用程序必须访问服务器来保存数据的次数。每当用户对大量字段（例如，对其用户信息）进行更改时，Facebook、Google（以及许多其他公司）都会使用“保存”按钮。
我试图避免使用“保存”按钮，因此每当用户关闭或刷新页面时就想到保存这些值。我也不知道这是否正确（如果断电，他们的系统关闭怎么办！），但我知道我可以这样使用它：
public void onClose(CloseEvent<Window> event) {
//save changes to the datastore
}
我在这三种方法之间左右为难，不知道该走哪条路！任何信息都会有帮助
谢谢！
In my GWT application, I have been saving everything that the user does instantly to the datastore in the background whenever they make changes. So far this has been fine because the things that the user can change aren't being changed a whole lot.
But now I have added a series of check boxes that the user can check & uncheck:
Would it be proper to save everything instantly to the database everytime the user checks/unchecks a box? The thing that's on my mind is reducing the amount of times my web application has to go to the server to save data. Facebook, Google, (and many many others) use a "Save" button whenever a user makes changes to a large amount of fields (say, to their user information).
I am trying to stay away from having a Save button, and so the thought came to mind about saving these values whenever the user closed or refreshed the page. I don't know if that's proper either (what if there is a loss of power, and their system shuts down!), but I know that I could use it like this:
public void onClose(CloseEvent<Window> event) {
//save changes to the datastore
}
I'm torn between the three methods and don't know which path to take! Any information will be helpful
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您当前的系统遵循一种非常出色的设计模式，许多应用程序（网络应用程序和其他应用程序）最近都在采用这种模式：消除“保存”的手动操作。我认为你应该坚持下去。
也就是说，如果您想减少往返次数和服务器负载，您可以执行以下操作： 您可以将正在进行的保存次数限制为一次，这样如果用户在您进行更改时进行更改，如果您正在等待“保存”请求完成，请等到该请求完成后再发送新请求。或者，您可以在用户进行更改时启动计时器，并在计时器到期时提交任何更改 - 这几乎就是 GMail 自动保存草稿消息的工作原理。
无论哪种方式，不要依赖关闭事件来触发向服务器发送状态：如果用户的浏览器崩溃，关闭事件将不会触发，并且他们将丢失所有更改。
Your current system follows a really excellent design pattern which a lot of apps (web- and otherwise) are picking up lately: Eliminate the manual operation of 'saving'. I think you should stick with it.
That said, if you want to reduce the number of round-trips and server load, you can do a couple of things: You could restrict the number of saves-in-progress to one, so that if the user makes a change while you're waiting for a 'save' request to complete, you wait until that request completes before sending a new one. Or, you could start a timer when the user makes a change, and commit any changes when the timer expires - this is pretty much how GMail's auto-save of draft messages works.
Either way, don't rely on a close event to trigger sending state to the server: If the user's browser crashes, the close event won't fire and they'll lose all their changes.