我写的有关Remoting文章的一些更改

随着对Remoting的逐步了解，很多技术在实现上会有一些变化，起初肤浅的认识会逐渐扎实起来。而自己以前在文中的很多结论会被自己不断的推翻。没有改变是不会有进步的，我喜欢这种改变！

我在《关于Remoting(续)》中这样写到：

对于Activated激活模式，不管是使用静态方法，还是使用CreateInstance()方法，都必须在客户端调用构造函数实例化对象。这样一来，在客户端我们提供的远程对象，就不可能只提供接口，而没有类的实现。

目前看来这个结论还是正确的。但是紧接着的结论就未免有些武断了。

所以对于Activated模式，我们必须在服务器和客户端提供两份完全相同的远程对象Dll，这个结果确实让人很沮丧。

真的是这样吗？其实这里我们可以用一个trick，来欺骗Remoting。既然是提供服务，Remoting传递的远程对象其实现的细节当然是放在服务器端。而要在客户端放对象的副本，不过是因为客户端必须调用构造函数，而采取的无奈之举。既然具体的实现是在服务器端，又为了能在客户端实例化，那么在客户端就实现这些好了。至于实现的细节，就不用管了。

那么远程对象有方法，服务器端提供方法实现，客户端就提供这个方法就OK了，至于里面的实现，你可以是抛出一个异常，或者return 一个null值；如果方法返回void，那么里面可以是空。关键是这个客户端类对象要有这个方法。这个方法的实现，其实和方法的声明差不多，所以我说是一个trick。方法如是，构造函数也如此。

还是用代码来说明这种“阴谋”，更直观：

服务器端：

     public   class  ServerObject:MarshalByRefObject
     {
        public ServerObject()
        {
            
        }

        public Person GetPersonInfo(string name,string sex,int age)
        {
            Person person = new Person();
            person.Name = name;
            person.Sex = sex;
            person.Age = age;
            return person;
        }        
    }

客户端：

     public   class  ServerObject:MarshalByRefObject
     {
        public ServerObj()
        {
            throw new System.NotImplementedException();
        }

        public Person GetPersonInfo(string name,string sex,int age)
        {
            throw new System.NotImplementedException();
        }        
    }

比较客户端和服务器端，客户端的方法GetPersonInfo()，没有具体的实现细节，只是抛出了一个异常。或者直接写上语句return null，照样OK。

我们称客户端的这个类为远程对象的替代类。

在《Remoting的几个疑惑》文章因为cls的帮助，解决了这个困惑。但今天又有新的困惑了。问题真是层出不穷啊。相信不断地提出问题，又不断地解决问题，学习Remoting最终可以满师吧？

这些困惑在《Remoting的几个疑惑》文后的评论已经写了出来，这里就不再啰嗦了。