Also note that in 9 out of 10 cases you don't need to implement either pattern by yourself. You just need to create a delegate and call its BeginInvoke method. This technique works correctly even if the target of the delegate is a Remoting proxy: in this case, Remoting uses its special asynchronous message processing path, and no threads are consumed from the local thread pool. See Ingo Rammer's book "Advanced .NET Remoting,"
Ron Ron Inbar/HFA/MS/PHILIPS wrote on 16/08/2007 07:57:15: > Regarding the two asynchronous programming patterns, this is what > the MSDN library has to say: > > “The IAsyncResult design pattern allows for a variety of programming > models, but is more complex to learn and provides a flexibility that > most applications do not require. Where possible, class library > designers should implement asynchronous methods using the event- > driven model. In some cases the library designer should also implement the > IAsyncResult based model.” > > The event-based pattern does not supersede the IAsyncResult-based > pattern, which is still the only way to work with asynchronous > delegates and to invoke WCF services asynchronously. I think the > event-based pattern was designed to address the relative difficulty > of implementing the IAsyncResult-based pattern correctly, since when > you implement an IAsyncResult-based asynchronous operation, you need > to test it with four different kinds of application code: polling > for completion, waiting for completion, blocking until completion, > and using a completion callback. > > Ron >
