问题2, 如何remote accessing?
考虑到wpf中已经将大部分对数据库逻辑的实现封装在一个assembly中,所以最简单的方法就是将这个assembly搬到Wcf端。
但是remote accessing 与 in-process accessing 并不相同。在in-process我们可以在一个类中暴露任意多的函数和接口让类的实现极其细粒度fine-grained.
Remote accessing 则不同,暴露越多的接口就意味着完成同一件事需要越多的函数调用。Remote accessing 中的函数调用的开销可不是函数push stack/pop stack那么简单。Client 和服务器要建立通讯,对函数的调用要封送成SOAP message,对message还要加密,网络的传输也需要时间和开销,同时在Server端要对client端坐的事情进行一个逆操做…如此多的事情要做! *所以在Wcf端的接口需要优化*
如何优化?Facade 模式是最好的优化pattern,将逻辑相近的functions在服务器端合并成一个function,从而减少多次函数的调用。合并后另一个问题是,被合并的这些子函数sub-routine每个都有自己的返回DataTable,并且这些数据集每个都是client端需要进行计算的,那么如何把这个数据集合并呢?
在.Net中解决办法很简单,使用DataSet将每个函数操作的返回的DataTable封装。之后DataSet作为最后的结果返回。在Client端根据相应的DataTable的名字从DataSet中取出DataTable.
下一个问题是可以继续优化么?
当然可以,DataSet本身有很多meta-data用于对数据集进行描述这个都是方便.Net framework的,但是在SOA的过程中这些是完全不需要的。所以优化的下一步是自己写一个DataSet/DataTable从而节省对meta-data传递的开销。从object => relation 的文章很多,只是需要权衡化这么多时间来做这件事是否值得。
如果是一个不大的项目,比如说几个人参与(和我现在的项目差不多)那么重新写DataSet/DataTable所花费的effort会远远大于meta-data传递的开销。但是如果是几十个或者上百人参与的项目,而且DataSet/DataTable的传输需要跨InterNet那么重新DataSet/DataTable绝对是一个精明的Architect需要考虑的事情。