(Was mistakenly posted as Re: ADVANCED-DOTNET Digest - 19 Oct 2005 to 20
Oct 2005 (#2005-198), sorry for the messup.)
As long as your clients call the method directly (i.e. not using .NET
Remoting), you can wrap a delegate's BeginInvoke and EndInvoke methods
with your own BeginXXX and EndXXX methods to make things a bit simpler for
the client. However, if you can't rule out the possibility that some day
your method will be called over a .NET Remoting channel, do yourself a
favor and leave the details of the asynchronous call to the client.
Otherwise you'll run into some non-trivial problems, including, but not
limited to, the following:
1. The default implementation of IAsyncResult is not inherited from
MarshalByRefObject and is not marked [Serializable]. Therefore, it is not
remotable, so you'll have to provide your own implementation.
2. Your IAsyncResult implementation will need to override
MarshalByRefObject.InitializeLifetimeService. Furthermore, your override
can't simply return null, because this way the object will never get
collected by the GC; so you have to start messing around with leases and
sponsors. You don't want that.
3. The completion callback that the client passes to BeginXXX cannot be
called by the server unless it belongs to a client-side object that
inherits MarshalByRefObject.
There may be other problems that I forgot to mention or that I didn't
personally run into.
To sum up: you should seriously reconsider what you hope to achieve by
implementing the async pattern vs. the considerable effort it takes to get
it absolutely right under all possible circumstances.
There's one exception, though: if your method is "inherently
asynchronous," such as the overlapped I/O performed by
{Begin,End}{Read,Write} then it's probably worth the effort. However, you
should still be aware of the Remoting issues I mentioned above.
Ron
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
