java数据引擎(十):应用三

应用之三(2014)

   公司在2013年11月接了某银行信用卡中心的影票客户端项目。

   该项目的应用由若干部分组成，包括客户端（ios和android）、公司服务器端（又分接口服务和后台管理）、银行服务器端。 部署在银行端的应用安全要求高，分成三个应用，即入口层、业务层和出口层，外部只能访问入口应用，业务的回调只能走出口。这样一共就是7个应用，除了ios外，都是用java开发的。

   笔者参与的就是公司服务器端和银行端的开发，并且敲定基本架构，前者的功能就是向客户端提供来自本地或者银行端的数据。

   由于是全新的项目，从开始设计时，就避开了之前老应用的冗长的难以维护的结构逻辑。比如，原来的好几个应用，每个接口的前部分都是进行参数的必要性、合法性校验、md5验签等，然后就是随处可见的构建json的响应逻辑，核心的业务淹没之中，要想理清楚，需要上下来回滚动，极不方便。现在将非核心的功能统统放在一个超类中，所有30多个接口都继承这个超类，每个接口只需像填空似的将业务功能完成即可。在struts.xml配置中，只用一行配置了所有 action。新加接口时，不需要动配置文件，即使应用在运行中，只需要将新加的接口编译好的class放入应用下，即可访问。这在之前的老应用是不可想 象的，因为老应用肯定要修改配置文件，肯定要重启服务。

   最主要的是，由于使用了通用数据引擎，就不存在所谓的dao层，也没有servie层。曾有一次，一个开发人员想将操作同一表的逻辑作一个公共封装，公共部分写好了，方法也写好了，结果发现，需要封装的方法也就三两行，仔细琢磨没有意义，因此放弃。为什么会这样？因为引擎已经最大限度的简化了，再想封装，也只能是减少表名作参数的传入，并且调用者的代码没有丝毫减少，这样就失去了封装的意义。

   举个引擎的应用细节，有个新增用户的接口，当银行端有新注册用户时，需要在本地库的用户表中增加一条记录，同时要将消息表的id与用户的id作为关联写入关联表中， 同时还有先判断是否已经存在该用户。这样，一共要操作三个表，三次查询，两次插入(插入的用户信息只有id和手机号)，实际用了7行代码完成，加上try catch也不会超过10行，简单得令人难以置信。要知道，这几行操作没有任何其它的辅助，也就是说，没有配置像hibernate那样的映射文件，也没有什么实体bean，也没有申明配置什么事务。

   在老应用中，数据的操作专门用了一个类，由于采用的是jdbc方式，里面的每个方法都要获取数据库连接，然后关闭连接。一般都是几千行，尤其其中的一个类达到12000多行，堪称超级航母。这种编程方式下，只要有新的数据操作，必然要加新的方法，因为要重用以前的逻辑，必须先了解一万多行里的可用方法。最终类的容量越滚越大。但是用引擎，就不会出现不断膨胀的超级巨类了。

   再说银行端的代码，由于只有三张表，数据逻辑也不多，因此还是用jdbc方式，当然如果以后业务扩展，肯定会膨胀。至于引擎，一来这是自有的东西，二来，银行对代码要求苛刻，你封装这么个东西，他们不一定放心，因此还是收拾起来为好(他们的代码也不外露，管理极严，用他们的机器开发，离开时，也复制不出来)。实际上，在去现场开发前，针对数据库db2的引擎已经准备好了。