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