这就是我需要的设计:我的设计理念。
对于服务的“橙色”部分,“订阅者”设计是一个好主意吗?
客户端需要连接到服务来执行“读取”和“写入”操作,并且他们还需要从服务获取通知(以 PUSH 方式)。
一开始我以为提供“读取”和“写入”功能的服务也可以发送通知(通过后台线程),但后来我明白“回调”仅在服务需要调用时使用在客户端上作为对客户端请求的响应。含义 - 服务无法发起对客户端的调用。那么“订阅者”设计是解决这个问题的正确方法吗?
这就是我需要的设计:我的设计理念。
对于服务的“橙色”部分,“订阅者”设计是一个好主意吗?
客户端需要连接到服务来执行“读取”和“写入”操作,并且他们还需要从服务获取通知(以 PUSH 方式)。
一开始我以为提供“读取”和“写入”功能的服务也可以发送通知(通过后台线程),但后来我明白“回调”仅在服务需要调用时使用在客户端上作为对客户端请求的响应。含义 - 服务无法发起对客户端的调用。那么“订阅者”设计是解决这个问题的正确方法吗?
所以简短的回答是肯定的——使用发布/订阅模式是众所周知的模型。它有助于将消费者与发布者分离。魔鬼在实现细节以及您可以处理多少复杂性以及您愿意在设计中交易什么。
如果您愿意接受它的权衡(必须是 WCF 客户端,您拥有客户端和服务)和限制(客户端直接耦合,网络拓扑限制),您可以从 WCF双工通道实现开始。
如果您不喜欢双工通道的限制,那么您可以考虑使用 MSMQ 或NServiceBus 之类的东西来满足发布/订阅要求。您可以使用Windows Azure AppFabric 服务总线将其提升到一个新的水平。
Duplex 可以独立地向客户端发送消息,而不仅仅是在来自客户端的呼叫到达时。
双工不耐用——当客户端离开或出现任何通信问题时,您必须从通道故障中恢复。保护双工可能很棘手。您必须在双方都有 WCF 客户端/服务。您必须了解您的网络拓扑。
您有 2 个不同的绑定上下文(系统)。一种是让客户端发送命令和查询,另一种是向想要收听这些事件的人发布有趣的事件。
编辑 - 如果某些客户端是 iOS 设备怎么办?使用 DUPLEX 会造成问题吗?你能开发一个通过 DUPLEX 通道与 WCF 服务通信的 iOS 应用程序吗?
答:在 iPhone 上看到这个 SO WCF 双工连接了吗?以及在开发可互操作的 WCF Web 服务时我应该知道什么?