最近一年的时间里忙于公司业务系统软件的开发工作，虽然公司委托第三方软件开发商进行软件的具体研发，但作为负责此软件项目的技术负责也不可避免地要去了解软件系统的架构，应用程序技术框架等。
为了使我们新的软件系统有很好的扩充性，我们采用了微软的软件工厂框架进行开发（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，调试也方便了许多。