我无法将故障通道的概念映射回某些绑定的手动实现.我认为这个WCF功能很烦人,我想知道是否有任何方法可以禁用它.
以TCP为例.大多数TCP通信都是断开连接的.那么为什么地球上的一个连接会对通道造成故障并破坏以下所有连接呢？
并命名管道？
也许我错了.所以请解释为什么它是一个功能,而不是一个bug.
Aas*_*set 11
我认为它是JuvalLöwy(WCF架构师之一)WCF整体理念的产物.引用他的书编程WCF服务:
这[异常系统和使用它的常规方式]是.NET作为平台的根本缺陷.[...] [在抛出异常之后],发生了一些完全出乎意料和可怕的事情.客户怎么可能假装不是呢？该对象可能无可救药地被破坏,但客户端仍在继续使用它.
毕竟,您的想法是与正在使用的传输通道的另一端的对象进行通信,如果对象抛出异常,它可能不再可用.这是一个有趣的观点,但我不确定我是否完全同意(因为,正如你所说,它在实践中可能非常烦人).
Faulted是CommunicationObject状态机的一种状态,它被烘焙到许多WCF抽象的实现中.它本质上意味着该对象的"游戏结束",所以你不会找到任何方法来禁用它.
它当然不是一个错误:CommunicationObject所有这些文物的基础状态机是一个有意识的设计选择.虽然可能有兴趣讨论WCF架构师做出的设计决策,但如果你想使用WCF,最终你只需要接受事情的发展方向.
您应该将通道视为不仅仅是正在使用的传输的适配器:它是更高级别的抽象,它包含通信堆栈中的许多不同层(传输,编码,安全性,会话管理,事务流,双工等).
即使查看特定绑定的详细信息,您也会发现堆栈中很少的元素具有容错性,以至于在先前的通信尝试失败后可以安全地重用它们(例如,可能是HTTP协议).即使你提到的那些(TCP,命名管道)也不像你建议的那样具有容错能力.
我认为CommunicationObject状态机或类似的东西或多或少是必不可少的,以便有一个通道抽象,它的工作水平高于其所有组成层/元素的细节.它启用了简单的规则:如果是Faulted,则将其丢弃并创建一个新规则.是的,在某些情况下,您可能会错过优化,这可能通过保留一些可以安全重复使用的资源来实现; 但这是您为更简单的通信抽象工作所付出的(小)成本.
| 归档时间： |
|
| 查看次数： |
1700 次 |
| 最近记录： |