在我的博客里，《Microsoft .Net Remoting[基础篇]》一文提到了用替代类来取代远程对象元数据的方法。有朋友对此有些疑惑不解，所以专门Post本贴以解惑。
我们在部署Remoting分布式应用程序时，通常要求接口与实现完全分离，这样可以保证元数据的安全。也就是说，在客户端部署程序集时，不应包括远程对象的实现。然而，如果我们采用的是客户端激活方式，这个目的就很难实现。为什么呢？我们首先来看看客户端激活方式与服务端激活方式在客户端的区别：
如果是服务端激活方式，方法如下：
RemoteObject obj = (RemoteObject)Activator.GetObject(typeof(RemoteObject),ObjectUri);
其中RemoteObject为远程对象，ObjectUri是知名对象的Uri。从其实现来看，它需要知道远程对象的类型，但并不需要实例化。如果我们令该远程对象实现某接口，那么在GetObject方法中，完全可以传递接口的类型，并返回接口类型对象。
再看客户端激活方式，方法有两种：
一是调用Activator.CreateInstance()方法，很显然，这种方法要求的类型必须是类对象，因为它要创建具体实例。
第二种方法是采用RemotingConfiguration.RegisterActivatedClientType()方法。虽然在该方法中，也只需要传递其类型即可。但这种方法要求在注册了远程对象后，必须实例化该远程对象：
RemoteObject obj = new RemoteObject;
显然要求的类型也必须是类对象，道理不言而喻。
那么，当我们采用客户端激活方式时，怎样让接口与实现分离呢？在拙文《Microsoft .Net Remoting[基础篇]》中，提到有两种方法。一是使用工厂模式，再以服务端SingleTon激活模式来模拟客户端激活方式；另一种就是使用替代类。
所谓替代类，就是仍然创建和远程对象类相似的类对象。所谓的类似，是指远程对象类的命名空间、公共方法、字段和属性均相同，但方法和属性的具体实现却采用空语句或无关实现的方式。我们来看看远程对象类和替代类的代码：
远程对象类：
public class RemotingObj:MarshalByRefObject
{
public void Foo()
{
//在这里可以放上许多业务;
Console.WriteLine("Just a test.");
}
}
替代类：
public class RemotingObj:MarshalByRefObject
{
public void Foo()
{
return;
}
}
从代码中可以看到，远程对象类的方法Foo()中，有具体的业务实现，而在其对应的替代类Foo()方法中，却只有一条简单的Return语句。
在部署的时候，我们将实际的远程对象类放到服务端，而把替代类放到客户端，这样就可以保护远程对象类的元数据安全了。
为什么可以这样呢？我们要知道，在Remoting中采用客户端激活方式时，虽然在客户端创建了远程对象实例，实际上此时只是创建了一个代理类而已，它真正指向的还是在服务端创建的远程类对象。我们提供这样一个替代类，就是用一种“欺骗”的方式，瞒过客户端，使其可以顺利地实例化这个代理类。而当我们在客户端调用这个对象的方法：
obj.Foo();
此时它将通过代理类去读取远程服务端的真实地远程对象。也就是说，此时的Foo()方法并非替代类的return语句，而是真正远程对象类的业务实现。
这种方法其实就是一个Trick，看似巧妙，不过在大型的应用时，其缺陷也是很明显的。由于我们要为每个远程对象都要实现该具体类，因此当远程对象众多时，带来的工作量也是可观的。这种方法也还算不上是真正的分布式应用。因此，大家如果要使用客户端激活方式，同时要求接口和实现分离，最好还是采用工厂模式，并以服务端SingleTon激活模式来模拟客户端激活方式。
附示例源代码下载。