Java Web 应用程序的任务模式
在企业 Swing 应用程序上实现某种类型的任务模式是很常见的。这是有道理的：您将拥有许多复杂的用户命令，这些命令可能需要（不同的）很长一段时间才能完成，并且您不能指望您的用户只是坐在那里等待。
但它在动态 Web 应用程序中的实用性又如何呢？假设我有一些基于 AJAX 的 Web 应用程序，以便用户可以在整个页面上发出各种命令，并且每个命令都作为独立请求发送回服务器。
任务模式是否适合此类应用程序的“请求处理机制”，或者当今的 Web 容器是否如此先进？多线程这样做会不会太过分了？
预先感谢您的任何意见！
It's pretty common to see some flavor of the Task Pattern implemented on enterprise Swing applications. It just makes sense: you'll have a lot of complex user commands that may take (differing) long periods of time to complete, and you can't expect your users to just sit there and wait.
But what about its practicality in a dynamic web application? Say I've got some web app that is heavily-based in AJAX so that users can issue all sorts of commands all over the page , and each of those commands get sent as standalone requests back to the server.
Is the task pattern an appropriate "request handling mechanism" for such an application, or are todays web containers so advanced & multi-threaded that doing so would be overkill?
Thanks in advance for any input!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我使用@Sanjay T. Sharma 的回复作为答案。我这样做是因为我希望获得 100% 的接受率，而且很明显，出于某种原因他/她不想回答这个问题。
（Sanjay 的）回答：
“……不需要向用户即时反馈的事情最好在独立的服务器/服务上处理，而“Web 容器”可以专注于为 Web 客户端提供服务。继续您的示例，当答案被接受时，“接受率”的更新在完成后并不完全“发送回”给客户端，而是异步反映在底层数据存储中，并在下一个数据存储中显示给用户为以下内容创建响应的时间用户”。
I'm using @Sanjay T. Sharma's response as an answer. I'm doing this because I like to have an acceptance rate of 100% and it's pretty obvious that for some reason he/she does not want to answer this question.
(Sanjay's) Answer:
"...things which don't demand instant feedback to the user are better off being handled on independent servers/services while the "web container" can focus on serving web clients. Carrying on with your example, when the answer is accepted, the updation of "accept rate" isn't exactly "sent back" to the client after it finishes but is reflected in the underlying data store asynchronously which is showed to the user the next time a response is created for the user."