其实也不能说是小技巧，只是大家可能会没有重视。这是需要先说明的，否则会被我的标题迷惑，因为我要描述的内容，真是寻常无比。
编写Remoting程序，通常分为三部分：远程对象、服务端程序、客户端程序。如果不考虑元数据的安全性，我们会把远程对象的dll生成相同的两份，分别放到服务端和客户端。Remoting在客户端的调用是很简单的，但调试起来就没有那么容易。因为客户端和服务器端分别属于不同的应用程序域，无法设置断点进行单步调试。如果了解NUnit，大家会知道NUnit也是不支持分布式应用程序的调试的，至少是支持得不够好。
所以，在实际做项目的过程中，我更倾向于先调用本地的对象，等调试成功后，再打开Remoting服务，调用远程对象，验证是否正确。举例来说，我要提供访问数据库的远程对象。我会先让该对象在本地运行，并调用其方法。如果一切正常，说明数据库的配置和连接均是正确的。然后再将该调用替换为远程对象。如果程序出错，则可以肯定是Remoting提供的服务出错了，或者是远程对象未按照Remoting的规定，没有派生MarshalByRefObject，或者未提供序列化特性。
最初我使用了最愚蠢的办法，就是写两行调用，一个调用本地对象，一个调用远程对象。然后根据实际的情况，酌情考虑注释某一行代码。如此这般用了一段时间，终于觉得麻烦，迫使我改变方法了。其实很简单，就是为客户端程序的主类中，多写一个构造函数而已，呵呵：）
例如，远程对象是一个访问数据库的Remoting服务，派生MarshalByRefObject的主类名为DBAccessService。那么我首先定义一个枚举，分别标明是属于本地调用还是远程调用：
public enum InvokeMode
{Local=0,Remoting}
对于客户端程序，如果主类为DataBaseOperate，那么就需要增加一个构造函数和远程对象字段：
public DataBaseOperate(InvokeMode invokeMode)
{
switch (invokeMode)
{ case InvokeMode.Local: serviceObj = new DBAccessService(); break; case InvokeMode.Remoting: serviceObj = (DBAccessService)Activator.GetObject(typeof(DBAccessService),"tcp://localhost:8080/DBAccessService"); break; 
} 
}private DBAccessService serviceObj = null;如此这般，在客户端调用对象时，就可根据设置构造函数中的参数枚举值，灵活地改变客户端调用对象的方式。
其实这种办法也可以用简单工厂模式来完成。不过这个简单工厂生产的产品和通常意义的工厂模式有点不一样哦，因为他们的产品其实是完全相同的。不同的仅仅是创建对象的方式而已。
public class SimpleFactory{ public static DBAccessService CreateInstance(InvokeMode invokeMode) {switch (invokeMode)
{ case InvokeMode.Local: return new DBAccessService(); break; case InvokeMode.Remoting: return (DBAccessService)Activator.GetObject(typeof(DBAccessService),"tcp://localhost:8080/DBAccessService"); break; }}
然后再调用工厂的静态方法，来获得该对象即可。
两种方法都是一种思想：就是根据需要，选择不同的创建方式（其实前一种方法也可以看作是简单工厂模式的一种变种）。如果只有一个要创建的对象，选前者更为方便；如果需要创建多个对象，用工厂方法提供多个静态方法，应该要灵活一些。
通过上述方法，不仅便于调试，也便于以后代码的修改。如果取消使用Remoting，只需改变参数枚举值即可，其他代码通通不用改变。这个技巧也算是设计模式的一种最简单应用吧。