CAE开发日志（1）：后台总体架构

1、CAE是什么

CAE全称是CallAnalysisEngine，即call表分析引擎，目前对外的名称是Caller，现阶段主要的功能就是查看call表，主要针对的是移动端的开发，但由于ios开发人员的欠缺，目前只开发了android端作为唯一客户端。

2、CAE的后台架构设计

目前CAE的后台使用Java实现，架构也是经典的三层架构，从上到下分别是Controller层、Service层、Dao层，主要使用的框架是Spring。

虽然目前java web的开发很多是使用SSH或SSM的框架，如果稍微简单一点的项目可能会考虑JFinal、Play框架，甚至是直接上servlet的开发模式，但是CAE的后台采用的是SSS架构，即Spring MVC+Spring JDBC+Spring来实现的，所以整个后台其实都是Spring作为主体，架构图如下：

3、不使用Hibernate/Mybatis作为ORM框架的理由

Hibernate的ORM味道很重，而且本身的重量级也非常大，可以肯定的是，如果Hibernate会用的话dao层获得的效率提升是很明显的，但是这也要求后台开发人员对hibernate的理解和使用比较深，目前我暂时只是了解过hibernate的一些基本用法，如hql、criteria、sql这些查询。当然hibernate还有二级缓存，但是后来发现其实并不是hibernate自己实现的二级缓存，只不过是和ehcache的整合而已，这个和spring 3.1后引入的缓存机制是一样的，既然如此，那就用已经有了的spring的就可以了，不需要再引入新的框架。

另外Hibernate对实体类的侵入设计还是比较要命的，如果以后要放弃hibernate时将会导致所有的实体类不可用，因为使用myeclipse反转生成的实体类都会有hibernate的注解，如果移除了hibernate的包，这些注解就会全部报编译错误。我曾经做过一个dao层从hibernate转移到jdbc的项目，那是一段痛苦不已的往事。

Mybatis的ORM味道就相对较轻，而且重量级也不大，顶多就一两个jar包就行，而且它主要是采用xml的方式来进行数据库访问，当然轻量级的代价就是需要自己写原生的sql，但我觉得这本身也是一件好事，没有什么比精心调制的sql更高效的了，还要考虑一个移植性的问题，例如我可以用hibernate的一些功能写出高效的数据持久操作，但是hibernate是有可能会被抛弃的，但是sql语句是比其更加坚韧，所以我认为与其花精力去学一个ORM框架如何高效地使用，还不如去学真正的sql调优。

说回mybatis，虽说mybatis比较轻量，但是它的一些规则比较碍手碍脚，如果应用的数据访问操作不需要太过灵活的查询的话，使用mybatis或许是一个不错的选择，但是CAE的查询并不是属于简单的一类，一个dao层的操作可能会涉及到多个sql甚至是事务的支持。但是，mybatis每个接口方法只能写一句sql！这让我非常的不爽，感觉手脚都被框住了，很不自由。我希望CAE的dao层能够更加自由地进行数据库操作（当然也要对dao层进行一定程度的封装才能实现），所以我并没有采用mybatis。

而使用spring jdbc的原因主要是，我没用过嘛，想借此机会学习一下，况且前面两个框架我都不感冒，所以就剩下一个spring jdbc了。

4、不使用Struts2作为MVC框架的理由

首先是考虑到未来的开发人员对后台代码的理解能力，我认为struts2的action层的概念其实并不能很好地被吃透，struts2的设计太过于理想化，太过于OOP了，导致他的action类也是高度OOP的产品，但是spring mvc是基于方法的拦截，代码看上去比struts2好懂多了，前端每个url的请求就是对应后台某个类的某个方法，简单粗暴，虽然spring mvc还是会操作一些web的原生对象，如HttpRequest、HttpSession等，但市场对它逐渐普及这一现象也证实了spring mvc的成功。

在我看来，struts2就是理想的化身，它追求OOP的思想，高度封装，也因此付出了一些代价（例如线程安全问题、效率问题），但是它依然坚持着要OOP，我认为这样的思想很美，但可惜它还付出了实用性的代价，而且最后生产出来的action也不一定能被新人理解。只能说，惋惜。

5、只使用Spring的理由

主要是希望CAE的后台的重量不要太大，如果引入了过多的框架，项目本身的体积就会比较大，而且spring本身就已经非常成熟，能够复用先用的逻辑为什么不去复用呢？除非现有的逻辑无法满足需求的时候，才会去考虑引入更多的框架去解决问题，但是目前来看，一个spring已经足够了。

而且jar包这么多，看起来超不爽的。

目前CAE的lib包体积只有19M左右，这已经是使用spring实现CAE的各个功能的最小体积了。

目前CAE使用到的spring的功能有：IoC、aop、jdbc、mvc、事务，后续可能会考虑加入缓存机制ehcache。

6、Spring的零注解风格

因为使用了Spring MVC，无可避免地就会使用@RequestMapping之类的注解来进行URL匹配的配置，既然controller层都使用了注解，那么干脆就整个应用都是用零配置吧！目前CAE后台的controller、service、dao层分别使用了@Controller、@Service、@Repository的注解进行三层架构的配置。

零注解风格使得程序可读性更强，而且避免了applicationContext.xml的过度膨胀，但是需要注意的是注解本身已经算是一种低侵入式的设计，之前说到的hibernate的注解的问题在这里依然会有发生的风险，只不过spring这个框架作为这个后台的总框架，遭到丢弃的可能性比hibernate低，所以暂时不需要去解决这个问题。