GWT 是否为您处理批处理,或者您是否必须编写执行此捆绑/批处理的逻辑?如果必须这样做,可以/应该捆绑哪些类型的调用?你怎么知道什么时候该关闭批次?
GWT-RPC 没有批处理机制。您可以(相对)轻松地添加一些,方法是在列表中排队“命令”,然后将列表作为单个 GWT-RPC 调用发送。一些项目应该用最少的努力为您做到这一点(例如 GWT-Platform)。
另一方面,RequestFactory 具有内置批处理功能:您创建一个RequestContext
实例并对其进行批处理调用,直到您完成它为止fire()
。
“客户端和服务器都是一次性的”;但“观点”不是一次性的
第一个与无状态有关(例如,使用 AppEngine,您无法控制何时创建、关闭或重新启动新的服务器实例:服务器随时可能消失,因此不要将状态保存在内存中)。
第二个是关于性能的:与浏览器中的 DOM 相关的一切都很慢,因此构建一个新视图(堆叠在一起的小部件)是重量级的(但对于 Cell 小部件来说则不那么重要)。因此,您不想让它们一次性使用,即不时将它们扔掉。您宁愿保留一个视图实例,以便在应用程序的整个生命周期内重复使用。
不完全相同的“可处置性”概念。
浏览器体现了会话(?!?!)
GWT 由单页应用程序构建。您可以在应用程序的变量中简单地将状态存储在客户端;您不需要 cookie 或其他任何东西来在页面之间共享状态。
服务器是无状态的 - 除了缓存(?!?!)
在服务器上存储会话状态是有代价的(状态必须持久化——特别是如果服务器是一次性的——在服务器之间共享——当你有一个集群/在云中运行时——等等。你将花费尽可能多的资源来维持存在您的会话状态作为实际的业务逻辑)。
客户端永远不会注意到重新启动(?!?!)
HTTP 是一个断开连接的协议。如果服务器重新启动,客户端将不知道它,它不应该知道它。
如果有人可以帮助我具体了解这 3 个项目以及它们之间的关系,我想我会开始“了解 gwt”。
这不是关于获得 GWT,而是关于获得 Web和获得单页 webapps,以及如何扩展它们。
无论它们是在客户端使用 GWT 还是 jQuery,在服务器端使用 Java、Python 还是 .NET,都无关紧要。
阅读 REST,它总结了一切。