一个分布式应用的常见的设计问题

注: 现在回头再来看看这个牢骚贴子,发现很多地方说的不当,没有将remoting和wcf 区别来说, wcf 通常需要确定的类型,因为它需要soap串行化,而remoting ,并不需要. 这里所讲的方式,其实是适合于remoting 而非wcf . 这个例子可以看成是如何 减少remoting service的发布和减少层间调用的例子.



分布式应用总有这样那样的限制，比方说不能使用范型方法，确切的说

IList<TEntity> FindAll(); 这样的方法签名是不支持的，但 IList<Customer> FindAll是支持的

c# 3.0的express tree 也不能作为参数传递，如此等等

通常，向服务器发起一个请求，然后得到结果，这个过程，一般就是先抽象接口和方法，然后实现，最后通过remoting,webservice或是wcf之类的暴露它

通常，做例子这个过程会简单，但实际应用中会有大量的接口和实现类,比方说一般中型的应用都是100个以上的数据表，于是乎，这个过程变得相当的繁琐

要节省接口和实现类 的数量，大概唯一的方法就是弱类型化，比方说 ，这样的FinAll方法签名

IList FindAll(string typename);

可以代替上百个强类型的方法签名

在设计时，通常这种问题需要架构师来做决定，该如何处理。比方说为了减少接口数量，定义一个ServiceDispatcher接口和实现 ，这段代码是随便打的,主要用于说明问题

public interface IServiceDispatcher{

object Call(string path,object context);

}

public class ServiceDispatcher ： IServiceDispatcher{

public object Call(string path,object context){

string[] s= path.Split('/');

//从容器获取服务类

object service= ContextRegistry.GetContext()[s[0]];

//用reflection调用方法

MethodInfo m=service.GetType().GetMethod(s[1],BindingFlags.Public | BindingFlags.IgnoreCase);

return m.Invoke(service,new object[]{context});

}

// 实现对应的服务，略

当客户端调用时可以使用这样的方式

IList<Customer> customers=(IList<Customer>)ServiceDispatcher.Call("customer/findall",null);

这种方式部署上有优势，只需要部署一个类，同时，一开始，你也无需特别的创建接口

但缺点也是很明显的，就是弱类型，作为开发者，要了解调用格式，输入，输出参数必须遵循分布式应用的规范，比方说在wcf中，需要使用DataContract和DataMember来标记参数中的业务类

此文的主要目的是想和大家探讨一下，在分布式应用中，如何减少客户端和服务端的交互部分的编码，不知道大家有没有什么特别的做法。