记工做中关于webservice上层业务框架的思考

    由于业务中有增长对外的接口考虑用webservice实现，定义了一套加解密格式规范，而后就是作一个简单的对业务逻辑的封装代码。

这个封装代码不能处理的有三块内容：外部系统的传入的数据定义，内部系统输出的数据定义，业务逻辑处理代码。

你们都默认承认的实现是由一个统一的对外函数参数和返回都是符合必定规范的xml

分歧出在了统一接口传送到内部业务代码的数据怎么封装上。

数据传送格式：

因为项目组中负责开发这块的对xstream比较熟悉，天然得选择了实体类封装数据，由父类封装通用数据，子类继承由开发人员本身定义。可是业务接口增多的状况下会有大量的冗余实体类，因此他提出了用map封装全部数据。另外一位同事提出了传json格式给业务代码。突然发现任何数据封装都是能够实现逻辑的，即便是xml字符串直接传给业务代码，只需提供统一的相似map的get和set方法，或者是xml上面封装一个数据类，由xml字符串作为数据的存储格式，下面提供get ，set和其余通用方法,并且这么作有个很大的好处就是极强的灵活性，毕竟业务代码是直接操做生成的xml的，缺点显然是效率问题，每次都是字符串xml的解析，不过话说回来用webservice原本就不是什么会考虑效率的业务需求，固然灵活性自己也会带来另外的问题。

概括了下有如下几种实现方案：

1.map封装数据     

优势：高效，灵活

缺点：没有实体类那么清晰的字段定义，不过对外系统通常会有详细的格式文档，这应该不是缺点

2.实体类封装数据  

优势：高效，结构清晰

缺点：会产生大量的冗余类，对于某些业务需求这应该不是问题，通常系统都会有对应表的实体类，若是业务需求上没有不少复杂的数据请求，是不会有太多冗余类的，并且这自己也能够有一些优化方案，好比某些数据在一个实体上的临时存储，不过对外系统有些不合适。或者创建有必定通用性的实体类。还能够在业务代码上再加一层工厂类作业务代码处理组装，在某些业务环境下会比较不错。

3.xml字符串封装类

优势：灵活

缺点：低效，并且把框架层的错误整到了业务代码中。

4.json等其余数据格式

//TODO

忽然发现数据格式的定义对于一个框架是如此的重要，作习惯了JAVA的业务代码，对于数据格式的考量愈来愈少。想到效率又想到这种业务用webservice这种技术是否合适的问题。反正是xml格式的文本，任何协议交互下均可以解决这个需求了，用webservice的好处又是什么呢？？？

//TODO