在Remoting客户端激活方式采用替换类以分离接口与实现

在我的博客里,《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激活模式来模拟客户端激活方式。

附示例源代码下载

posted @ 2004-12-06 13:49 张逸 阅读(...) 评论(...) 编辑 收藏