上面的示意图中,步骤7指向的Remoting Server就是Host程序,
而Remoting Server包裹着的RemoteCustomer就是真正提供服务的数
据操作类。
以下所列代码即为该类的部分实现:
代码13:使用Data Access Logic进行Remoting调用 – 3,RemoteCustomer
public class RemoteCustomer: MarshalByRefObject { public RemoteCustomer() { }
public ArrayList GetAllCustomers() { SqlConnection conn = new SqlConnection( Helper.GetApplicationSetting("ConnectionString"));
// 通过ObjectSpaces获取所有Customer数据 ObjectSpace os = new ObjectSpace( Helper.GetApplicationSetting("MappingFile"), conn);
ObjectSet ost = os.GetObjectSet(typeof(MyCustomer), "");
// 以ArrayList方式返回所有Customer数据 // 注:当前版本中,ObjectSet对象通过Remoting进行传递有 Bug ArrayList al = new ArrayList(ost);
return al; } } |
作者相信,在看完代码后,肯定有些朋友会产生这样的疑问:
代码13中的RemoteCustomer完成的也是我们前面分析过的
Data Access Logic所能完成的工作,虽然当中隔了一层Remoting,
但本质相同,难道就不能与代码11,12中的CustomerDal_ORM进行
一次“有效重组”吗?
回答是肯定的!
不过,我们还是需要做两个非常简单的操作:
(1) 大家还记得代码9中的DalBase吗?只要我们令它从MarshalByRefObject继承(原先是默认的object),即可“轻松”解决这个问题!但也别高兴太早,一旦如此,所有其它的Data Access Logic类也将不得不接受这“多余的馈赠”L,要知道,毕竟通过Remoting进行Data Access Logic操作的机会还不是很多(一般通过Business Logic即可解决问题),这样的“馈赠”并不是人人可以消受的(这也是作者并没在DAF Solution中这么实现的原因)!
(2)将上述RemoteCustomer的代码并入CustomerDal_ORM中,但是,请注意:别忘了将方法名称改掉(因为已经有一个GetAllCustomers方法存在,虽然返回类型不同,但任何.NET下的Compiler都是无法区分这种差别的J)!