最近一年的时间里忙于公司业务系统
软件的开发工作,虽然公司委托第三方
软件开发商进行
软件的具体研发,但作为负责此
软件项目的技术负责也不可避免地要去了解
软件系统的架构,应用程序技术框架等。
为了使我们新的
软件系统有很好的扩充性,我们采用了微软的
软件工厂框架进行开发(SCSF),这样,我们的应用程序可以很容易地进行功能模块的扩充,把
软件需求变更对整个系统的影响减少到最少。
在此
软件开发过程中,由于刚开始的小小失误,我们在做业务模块开发时,象大家通常做的那样,把每个模块分成业务逻辑层(BLL),业务实体层(Model),数据访问接口层(IDAL)及SQL数据访问层(SQLDAL);为了加快开发进度,我们就把
webService放在一边以后再考虑,等到所有模块做完了,要进行跨互联网测试时,这才意思到
webService的代码工作量有相当大的工作量,同时要提高程序响应速度,势必要对数据传输进行压缩,即使把业务层方法简单通过
webService发布出去不做压缩,也要对UI进行改动;看到将近二十几个模块,想想都头大!!!
没办法,即使走到了这一步,项目还是要按时完成的,只能想其它办法,手工写指定不行的。那能不能自己做个工具做此类事情呢?写了几个
web服务方法,由于只是重写BLL里的方法签名,加个属性等,看看所有方法都是同一模式;由是就有了写个工具自动根据类库里的方法生成
webMethod的相法。
之前就听说过微软的CodeDOM模块,感觉很是神奇,同一步代码对象图可以根据需要生成C#,VB.NET等源代码文件;如果再结合反射,那么就可以很容易达到我的要求了。 使用反射读取类库的中每个方法元数据MethodInfo,根据读出来的元数据生成相应的
webMethod的CodeDOM对象。
技术问题解决了,仔细一想,还是有问题。 之前说过UI直接引用Model及BLL,我把BLL通过
webService发布出去后,如果一个方法返回的是一个业务实体,那么这个返回值的类型和Model中的就不是同一类型了;同样的问题也存在于
webMethod的参数中,我还是要改UI中的代码。
在工具生
webService代码的同时,我也生成了一个新BLL类库的所有源码,类库中的类所属命名空间,类中的方法签名与原有的BLL中的类完合保持一致,只是方法内部实现调用
webService代理类中的方法而已,这样以来,我的UI只需要删除对原有BLL的引用,转而引用新的基于
webService的BLL类库即可。同样,即使
web服务方法返回时业务实现的类型发生的改变,那我只要不直接返回实体对象,而于把对象序列化后返回Byte[],在新的BLL方法中,再把Byte[]流反序列化进业务实体,如法炮制,
web服务方法的参数也做同样处理;这样,UI在相应的Model方面的代码一点也不需要更改。由
webService方法参数及返回值都是Byte[],所以很容易加入压缩功能。
问题总算解决了,有了现在工具,根据Bll层类库,可以在一二十分钟内搞定
webService,同时,模块开发时没有
webService,调试也方便了许多。