ASP.NET网站制作之WCF的成绩和Using语句块仓酷云 - 仓酷云

ICommunicationObject（它是ServiceHost，ClientBase，IChannel，IChannelFactory与IChannelListener终极承继的对象）老是具有封闭对象的两个办法：（a）Close，（b）Abort。依照字面的了解，假如但愿自动封闭对象，则挪用Close；若要强迫封闭则挪用Abort。
因而，Close()办法会吸收一个Timeout参数，并包含一个异步版本（由于它大概堵塞线程），并且Close()还会抛出非常。Close抛出的非常为CommunicationException（CommunicationObjectFaultedException是其子类）与TimeoutException。
相反，Abort()其实不会堵塞线程（也不会抛出任何非常），因而没有Timeout值，也其实不包括异步版本。
这两个观点从最后的Indigo一向相沿至今[译注：所谓至今是指Brian宣布帖子的工夫2006年10月25日]。就今朝而言统统一般。
最后的界说为ICommunicationObject:IDisposalbe。作为一个标志接口，我们以为它能够用于关照用户在大概的时分马上开释对象。但是成绩却相继而来。
从Beta1版本入手下手，我们修正了Dispose()，让其同等于Abort()办法。一部分缘故原由是Dispose()应当完成最最少的需要的对象清算事情。在Beta1中，这大概算得上是我们的头号贫苦了。用户能够将它们的通道（channel）对象放在using()语句块中，缓存中任多么待被掏出的动静都大概会丧失。事件没法提交，会话大概失掉告诉收到（ACKed）的动静等。
鉴于用户的反应，在Beta2中我们又修正了完成，让Dispose()近似即是Close()。我们晓得，非常的抛出是成绩之地点（部分缘故原由在这篇帖子中已申明），因而我们试图让Dispose变得加倍“伶俐”。那就是说，假如以后并不是Opened形态，就会在外部挪用Abort()。这仍旧存在一系列成绩，最次要的是你没法从牢靠性角度揣度体系。Dispose仍旧会抛出非常，但并不是老是会关照你某些事变产生毛病。终极，我们决意将IDisposable从ICommunicationObject中移走。经由几番狡辩，IDisposable在ServiceHost和ClientBase中被保存了下来，由于从实际上讲，关于多半用户而言Dispose抛出非常仍旧是能够承受的，他们更倾向于利用using()的便当性，具有该标志接口就能够更实时地扫除对象。你大概主意（我们的一部分隔发职员抱有一样的立场）：应当将它从这两个类中移走，但是好也罢歹也罢，我们毕竟作出了选择。关于这个成绩，你永久都不成能告竣分歧，因而我们在SDK样例中给出了最好理论，那就是遵守try{Close}/catch{Abort}范式。