Silverlight 4 Duplex 服务 - 停止回调
我有一个 Silverlight 4 应用程序，它通过创建客户端回调来使用 WCF 双工。从客户端，我有一个从数据库中检索所有行的方法（不是真的，但对于这个例子）。每行都使用回调发送到客户端。我需要弄清楚如何在开始后中止这个过程。例如，假设我厌倦了看到该表中的所有行在屏幕上滚动。我想查看另一个表中的行。如何在第一个动作进行到一半时停止它？
我以为我可以在服务器上创建一个新操作来中止处理，但这不会对已经通过回调发送并等待客户端接收的内容执行任何操作。
我正在寻找一种方法来保证一旦新的搜索开始，我不会有任何旧数据会被客户端获取。有谁知道实现此目标的最佳方法吗？
有趣的是——在使用双工服务之前，我的问题是我无法足够快地获取数据。现在我正在使用双面打印，我无法将其关闭！
I have a Silverlight 4 application that uses WCF duplexing by creating a callback to the client. From the client, I have a method that retrieves all rows from a database (not really, but for this example). Each row is sent to the client using the callback. I need to figure out how to abort this process once started. For example, say I'm tired of seeing all the rows from this table being scrolled by on my screen. I want to see the rows from another table. How do I stop the first action while in the middle of it?
I thought I could just create a new operation on the server to abort processing, but this won't do anything with what's already been sent through the callback and waiting to be picked up by the client.
I am looking for a way to guarantee that once the new search starts, I don't have any old data laying around that will get picked up by the client. Does anyone have any idea on the best way to accomplish this?
It’s funny – before using duplex services, my problem was that I could not get data fast enough. Now that I am using duplexing, I can’t get it turned off!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我可以想到两种方法来解决这个问题。注意：我也没有测试过，毫无疑问还有其他的。
(1) 在客户端或服务器端，中止连接并重新建立新连接。有点老套，根据我的经验，围绕这种“现在你看到了现在你看不到”的连接进行编码是 PITA。
(2) 在服务器端，最初只发送一定量的数据，并缓存其余的数据，直到收到客户端的通知，表明您确实想要查看下一位。这类似于许多“分页”UI 使用的方法。其变体是不将数据排队，而是对客户端的调用排队。将它们放入某种 Action 变量中，将它们排队，只有在客户端说“是的，给我下一个 50 个”时才执行回调。
不幸的是，我不知道有什么方法可以告诉OperationContext，“中止所有待处理的调用，但保持通道处于活动状态。”也许它就在那里，但我一直没能找到它。很高兴有更多知识和经验的人纠正我。
I can think of two ways to approach this. NB: I haven't tested either, and there are undoubtedly others.
(1) On either the client or the server side, abort the connection and re-establish a new one. Kind of hacky, and I can speak from experience that coding around this sort of "now-you-see-it-now-you-don't" connection is a PITA.
(2) On the server-side, only send a certain amount of data initially, and cache the rest, until you receive a notification from the client that you actually do want to see the next bit. This would resemble the approach used by many "paging" UI's. A variation of this would be to queue not the data, but the calls to the client. Throw them in an Action variable of some sort, queue them up, and only execute the callback once the client has said, "Yup, give me the next 50."
Unfortunately, I don't know of any way to tell the OperationContext, "Abort all the pending calls, but keep the channel alive." Maybe it's there, but I haven't been able to find it. Happy to have someone with more knowledge and experience correct me.