【发布时间】：2011-08-09 20:44:00
【问题描述】：
也许我做错了，但这是我目前的“设置”。
我有一个 silverlight 客户端，它使用 Caliburn.Micro 和一个带有“LoadCatalog”类的 MEF 容器，以 MVVM 方式保持一切松散耦合。
我有一个保存所有接口的“通用”dll。
我所有的视图和视图模型都是单独的项目，它们只引用公共 dll。
视图模型使用 WCF（常规）与后端通信。前端本身与后端有双工连接。
现在想到问题了。每当后端认为是时候在前端出现一个新屏幕时，它就会使用回调通道告诉前端加载下一个屏幕。
这看起来是一个很好的使用模式吗？或者我应该将管理何时加载到前端？我认为在后端有这个很好，但也许这是我不知道的某种反模式，因此提出了问题。
现在为了争论，假设我想把它放在后端。
在后端管理回调通道集合的最佳方式是什么？如果我在所有常规 WCF 端点以及双工通道上启用 SessionMode.Required，这是否会在多个端点（常规+双工）上保持状态？或者这种状态是否只会在单个端点内持续存在？ 我的猜测（从到目前为止我能够做的测试）是我需要添加一些逻辑，例如，一旦建立回调连接，就为前端提供一个 guid。然后在常规端点连接中使用该 guid，以便后端知道它是哪个“客户端”。
如果我收集了我收到的回调通道，我是否“曾经”能够可靠地收集所有通道并检测当前状态？我现在可以拦截回调通道（只有 1 个实例 atm，没有收集或任何东西，所以单个用户）并使用它来告诉前端要做什么。但是有时当客户端突然停止（换句话说，当发生错误时）并且我再次启动客户端时，似乎之前的（故障？）连接仍然被“重用”或其他东西，没有运气所以通信流停止连接双工端点后。
这有意义吗？
希望有人对这件事有一些经验，可以为我提供一些启示。我不是完全的新手，但关于多重连接和保持它们分开，我可能需要一些正确方向的指针。
谢谢！
休伦。
【问题讨论】：
-
我设法让它运行起来。这是我所做的：
-
我设法让它运行起来。当我创建从前端到后端的双工连接时，我返回一个唯一的 Guid。从现在开始，我使用这个公会与后端进行所有通信。这使得后端“识别”客户端。在后端，我有一个连接列表（获取回调通道并将其与 Guid 一起存储）。只需确保在迭代列表对象或从中添加/删除项目时锁定列表对象，因为它会被设计用于多个线程。到目前为止，从后端获取控制权的模式似乎效果很好。