编写离线工作的应用程序（Web 应用程序）
当编写一个离线和在线工作的应用程序时，最好编写一次离线工作，并且在线模式将与离线模式一样工作？
例如，我们有一个典型的购物车示例。购物车包含商品和顾客。
加载购物车后，我是否应该将所有商品和客户缓存在本地存储中，并在线和离线使用该数据缓存，并根据需要更新缓存？开发离线/在线混合 Web 应用程序时有哪些最佳实践？
When writing an application to work offline and online is it best to write it once to work offline and the online mode will work the same as offline?
For example lets see we have a typical shopping cart example. A shopping cart contains items and a customer.
When the shopping cart is loaded, should I cache all the items + customers in local storage and use that data cache for both online and offline and update the cache as needed? What are some best practices when developing an offline/online hybrid web application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
编写以在线/离线模式工作的 Web 应用程序实际上非常类似于编写任何“普通”服务器驱动的 Web 应用程序，不同之处在于您有一个位于应用程序和数据之间的数据访问层 (DAL)存在于服务器（在线模式）或浏览器数据（离线模式）上。
根据应用程序及其需求，您可以以两种模式之一运行：a.) 缓存并尝试最佳模式或 b.) 加载所有内容并检查更新模式。
这两种模式中的每一种都有一些好的部分和一些坏的部分，并且您的应用程序肯定可以有不同的部分以一种或另一种方式倾斜。
缓存并尝试最佳模式
对于此模式，DAL 在正常操作过程中访问数据时会将数据从服务器缓存到浏览器的数据存储中。一旦进入离线模式，DAL 会尽力满足用户的请求，但它只有缓存的数据可供使用，因此某些操作可能无法完成（或至少不能立即完成）。从好的方面来说，等待数据加载的启动时间很短，但从不好的方面来说，每个操作都需要服务器命中（如果已连接）并且必须缓存该数据。对于由于数据不完整而无法完成的任何操作，应用程序还必须正常失败。
加载所有内容并检查更新模式
在这种情况下，DAL 在应用启动时将应用所需的所有数据加载到浏览器中。如果应用程序已加载，则必须更新所有数据以确保缓存不会过时。从好的方面来说，用户不必等待很长时间才能做事，因为一切都是本地操作，但从坏的方面来说，如果有大量数据，启动时间可能会很长。相当长。
无论哪种情况，您都必须应对过时的缓存问题以及服务器离线操作持续存在的问题。这意味着在启动时，并且可能在应用程序运行时定期，您将需要同步回服务器以保持缓存数据最新，并与服务器共享您可能拥有的任何仅本地状态，以便世界其他地方可以看到该应用程序实例的更新。
当与该操作相关的数据在应用程序更新之间发生变化时，将应用程序处于离线模式时发生的操作保留回服务器可能会特别棘手。例如，如果缓存的银行余额已过时，并且显示的金额比服务器反映的“真实”状态多得多，则用户可能会在不知情的情况下透支帐户。这是一个极端的例子，但是这种操作冲突检测需要到位，以处理可能相互冲突的更新。
一般来说，如果您有一个可以同时在线和离线的应用程序，请编写该应用程序，以便应用程序本身不需要关心。较低级别的数据层抽象了所有问题，您的应用程序只需要知道如何处理无法获取所需信息的情况（任何好的应用程序，无论是在线还是离线，都应该这样做）。
对于购物车，您可能（或希望？）拥有比任何单个客户可能放入购物车的产品更多的产品。将所有这些内容加载到每个人的浏览器中几乎肯定会造成巨大的带宽浪费，并且会给您的用户造成如此大的延迟，以至于巨大的带宽成本和销售损失（由于响应时间慢）将很快使任何业务陷入困境。根据需要将产品加载到浏览器数据中，如果您愿意，您可以加载“其他用户也购买”的与购物车中实际商品相关联的其他产品。
Writing a web-app to work in an online/offline mode is really very much like writing any "normal" server-driven web app, with the exception that you have a data access layer (DAL) that sits between your app and the data living on either the server (on-line mode) or the browser's data(offline mode).
Depending on the application and it's needs, you can run in one of 2 modes: a.) A cache-and-try-your-best mode or b.) a load-everything-and-check-for-updates mode.
Each of these two modes has some good and some bad parts, and you can definitely have different parts of your application that lean one way or the other.
Cache-and-try-your-best mode
For this mode, the DAL caches data from the server into the browser's data stores as it accesses data during it's normal course of operation. Once in offline mode, the DAL tries it's best to meet users' requests, but it only has the cached data to work from and so some operations may not be able to be completed (or at least not right away). On the up-side, there is minimal start-up time waiting for data to load, but on the down side, every action requires a server hit (if connected) and that data has to be cached. The app also has to fail gracefully for any operation it can't complete due to incomplete data.
Load-everything-and-check-for-updates mode
In this case, the DAL loads all of the data the app needs into the browser when the app starts. If the app has already been loaded, then all of the data has to be updated to make sure the cache isn't stale. In the up-side, the user doesn't have to wait very long to do things ever, since everything is a local operation, but on the down-side, if there is a lot of data, the start-up time could be rather long.
In either case you have to battle stale cache issues, and issues persisting off-line operations to the server. This means that on start-up, and probably also periodically while the app is running, you will need to sync back to the server to keep your cached data fresh, and to share any local-only state that you may have with the server so that the rest of the world sees the updates from that instance of the application.
Persisting operations back to the server that occurred while the app was in offline mode can be particularly tricky when the data involved with that operation changes between updates of the app. For example, if a cached bank balance is out-of-date and indicates much more money than the "true" state reflected by the server, a user could overdraw the account without knowing it. This is an extreme example, but this sort of operational collision detection needs to be in place for handling updates that may run into each other.
In general, if you have an app that could be both on- and off-line, write the app so that the app itself doesn't need to care. A lower-level data layer abstracts away all of the problems, and your app only needs to know how to deal with not being able to get information it wants (which any good app, on- or offline, should do).
For a shopping cart, you likely (or hopefully?) have WAY more products than any individual customer is likely to put in their cart. Loading all of them into everyone's browser is almost certainly a HUGE waste of bandwidth and would cause such a delay for your users that the massive bandwidth cost and lost sales (due to slow response times) would quickly sink any business. Load the products into the browser data as-needed, and if you want to, you could load other products that "other users also bought" that are associated with the items actually in the cart.