Shhh... Don't Tell Anyone but I am using .NET Remoting: Part 4 - Wrap it up

Here is the final trick. And those of you who have read the series have waited a while for this final post. (Sorry for the delay.) Programming against an interface gives you the consistent programming model across the various distributed platforms but abstracting the code that creates the proxy is also critical to hide the .NET Remotingisms from your client code as well.

Take for example the following line from the previous post:

IHello proxy = (IHello)Activator.GetObject(typeof(IHello), "tcp://localhost/Hello.rem");

The use of the Activator class implies a specific distributed application stack so hiding that from your implementation will ease migration to alternate or future stacks with limited client impact. The same holds true for the hosting code written to register objects and channels but this code is often already isolated in the service startup routines (e.g. Main or OnStart for a service).

The easiest way to abstract away the proxy generation code is to use a basic factory pattern on the client that creates the proxy classes. This has the added advantage of enabling the developer to use pooling or handle lifetime issues but the core value for this conversation is the abstraction of proxy creation.

Here is a simple example:

public static class HelloClientProxyFactory

{

            public static IHello CreateHelloProxy()

            {

                        return (IHello)Activator.GetObject(typeof(IHello), "tcp://localhost/Hello.rem");

            }

}

As you migrate forward from .NET Remoting to other platforms (e.g., Indigo) this proxy factory can be updated and deployed to your clients enabling the client programming model to remain entirely unchanged but allow your developers to move to a completely different distributed application stack underneath.

This concludes the Shhh… series but I have more post planned for the migration story from .NET Remoting to WCF (“Indigo”).

Stay tuned.