|
1：socket VS remoting
使用socket无疑是效率最高的。但是，在复杂的接口环境下，socket的开发效率也是最低的。故在兼顾开发效率的情况下，可以使用remoting来代替socket开发。并且：
1、Tcp通道的Remoting速度非常快。
你可以通过端口查看工具，发现remoting比直接socket传输的内容，应该是属于同一个数量级的。我的另一个担心是，大客户端数量的情况下，remoting传输效率会不会很低，结果经过现场测试，同时对300个客户端进行数据通信，不存在信息丢失情况。
2、虽然是远程的，但是非常接近于本地调用对象。
也就是完全符合面向对象思想。
3、可以做到保持对象的状态
直接使用socket传输机制，我们必须花大量的精力来处理异常、断网、死机等现象，使用remoting，这些工作会大大简化。
2：remoting vs webservice
1、webservice在framework2.0状态下只能寄宿于IIS等应用服务器中。微软直到3.0才提供了servicehost来寄宿webservice，这就极大地限制了webservice在使用中的灵活性。在framework2.0环境下，如果你有一个应用要脱离IIS而存在，就不得不抛弃webservice。（除非你想代码实现一个WEB应用服务器）
2、remoting可寄宿在你自己的代码中，也可寄宿在windows服务及IIS中。最大程度的提供了开发和部署的灵活性。
3、remoting在使用http通道的时候，也如webservice一样支持穿透路由。
4、remoting与websercie相比，提供双向通信。哪怕是将remoting寄宿在IIS中，也支持。
5、webservice客户端自动生成的代理类比较复杂。而remoting一般来说，都是手动编写客户端代码。
6、当然，webservice最主要优势是，它是一个行业标准，而remoting只是微软自己内部的标准，如果你的应用要脱离微软的平台，就只能使用webservice了。
3：remoting vs wcf
与wcf的比较，更多的是从平台的普及度上来说。在当前环境下，2.0的普及度还是最高的。如果哪一天3.0甚至4.0普及了，当然WCF是最好的。
4：最简单例子
下面给出一个极其简单的Sample：
4.1远程对象
首先，创建一个项目，名为 RemoteObject，该项目经过编译后产生的DLL文件要在remoting客户端的项目和服务器端的项目中被引用。该项目包含一个类 MyObject， 即 Remoting使用的远程对象，如下：
using System;
using System.Windows.Forms;
namespace RemoteObject
{
public class MyObject : MarshalByRefObject
{
private int i = 0;
public int Add(int a, int b)
{
return a + b;
}
public int Count()
{
return ++i;
}
}
}
4.2Server端
新建项目 RemoteServer（控制台）， Server端要引用MyObject的DLL。
using System;
u |
