2019独角兽企业重金招聘Python工程师标准>>> 
因为业务中有增加对外的接口考虑用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