我目前正在使用c＃构建ASP.NET MVC Web应用程序。
我想确保构建此应用程序，以便将来可以扩展，而无需进行重大的重新分解。
我非常热衷于使用某种队列将任何写入发布到我的数据库库，并且有一个进程可以异步轮询该队列以执行更新。将此数据发回数据库后，客户端需要使用新信息进行更新。这意味着根据服务器上执行的业务规则，将数据写回数据库的过程可能需要一段时间。
我的问题是从客户端\浏览器角度处理更新的最佳方法。
我正在考虑将数据发布回服务器并将其添加到队列中并立即向客户端发送响应，然后以某种频率轮询以获取更新的数据。任何最佳实践或模式都将受到赞赏。
另外，在从数据库中读取数据方面，您建议使用任何特定技术，或者根据我的方案直接从数据库中读取数据。
更新 以为我会发布一个更新，因为它已经有一段时间了。我们实际上最终使用的是Windows Azure，但该解决方案适用于其他平台。
我们最终做的是使用Windows Azure Queue将消息\命令发布到。这是一个非常快速的过程并立即返回。然后我们有一个worker角色，它在另一个线程上处理这些消息。这使我们能够在理论上最小化Web角色上的任何db write \ updates，从而使我们更容易扩展。
我们处理通过电子邮件通知用户，甚至根据我们正在处理的数据类型静默地通知用户。
答案 0 :(得分：2)
不确定这是否有帮助，但为什么不会每30秒在页面上自动刷新一次。这有时是新闻提要在体育网站上的运作方式，并说该网页每隔x分钟就会更新一次。
<meta http-equiv="refresh" content="120;url=index.aspx">
答案 1 :(得分：1)
为什么不让用户手动轮询请求的状态？这就是典型的电子商务应用程序的实现方式。当您在线购买商品时，订单会被提交到队列中以供完整填写。提交后，会向用户显示“感谢您的订单”页面以及可以查看订单状态的链接。用户可以随时访问链接以检查状态，无需自动轮询机制。
你的情景与此有何不同？
答案 2 :(得分：0)
对不起我之前的回答我可能会误解。我说的是一个“队列”作为存储在SQL DB中的东西，但是当你再次阅读你的文章时，你可能在谈论一个单独的消息排队组件，如MSMQ或JMS？
我永远不会在前端，用户和后端SQL DB之间放置一个消息队列。队列适用于跨时间缩放，适用于后端组件，处理时间的差异是可接受的（例如订单履行）......在与用户打交道时，这种差异通常是不可接受的。
答案 3 :(得分：0)
虽然我不知道我是否同意原因的逻辑，但我知道像jQuery这样的东西会让你的生活变得更轻松。我建议制作一个客户端代码消耗的RESTful Web API。例如，您想要向系统发布新订单并让客户响应？发帖到www.mystore.com/order/create并返回新URI以访问订单（即订单＃）作为URI（www.mystore.com/order/1234）。然后将该响应存储在客户端代码中，并设置jQuery call以轮询响应或停止轮询错误。
如需进一步阅读，请查看有关REST概念的this Wikipedia article。
此外，您可能会考虑Reactive Extensions for .NET并在其中查看RxJS子项目，该子项目具有一些非常灵活的处理轮询问题的方法，而不会导致您自己编写轮询代码。有趣的事情玩！
答案 4 :(得分：0)
也许您可以在UI中添加“待处理交易”区域。对事务进行排队时，将其添加到用户的“待处理事务”列表中。
完成后，在下次申请新页面时在用户的“待处理交易”列表中显示。
您可以将完成的交易保持列出，直到用户点击它或预定的时间长度。