有的公司有积累，可能在此上面花费的时间比较少，有的没积累，可能为了选择什么样的框架，为了优缺点争论不休，耽误个把月时间都有可能。

我希望在此给出一个GPS平台的标准模版，供大家参考，统一思想，快速进入状态。

平台自然是基于传统的MVC模式的思想来开发，自不待言，而MVC框架，我选择专注于控制层的Struts2,框架，专注于容器管理，面向接口和服务开发的Spring框架，专注于持久层的Hibernate、iBatis框架。专注于通信层开发的Mina框架。

采用框架，我首先想到的一点，就是约束和统一，在团队开发中，最忌讳的就是不统一，团队中我们总有些开发技术稍微落后，思想跟不上的成员，靠沟通是没有用的，而是要小孩子的学步车一样，强行把他框在一个范围内做开发，让他跟上总体的开发水平和节奏。不懂得MVC什么意思，也勉强能做出MVC的东西。所以现在的所谓的架构师，很多都是对这些东东玩的转，玩的多了就慢慢有了架构的思想，就想玩游戏，玩多了，就对游戏体验关卡设计有了感觉，再深入了解后，就开始有了格局，开始注重设计了.

1) Hibernate框架

  这个只要是做Java开发的，基本都在用，除了基本的ORM映射功能之外，我选用它，主要是很方便的自动创建表，在更新实体类的属性后，自动更新库表字段，以及可以方便移植到不同的数据库中，使用Hibernate框架，维护多个关系数据库。只需要维护不同的数据库配置的xml文件，而不是维护多个代码版本。

  如果使用PowerDesigner工具结合起来，从建模到代码自动生成到逆向更新模型，简直是后台开发人员的最爱。

2) Ibatis框架

  这个是将开发人员从写SQL，根据查询条件，动态生成SQL的地狱中，拯救出来。

  很多平台代码量貌似很大，其实都是唬人的，因为重复的写代码，代码行数能不大吗。比如GPS平台中，几十个、上百个报表，每个报表都有四五个动态组合查询条件，你如果自己在代码中拼SQL，代码量很壮观，但是很低级，工作很低级，很容易出错，错了也很难跟踪。也不容易移植。如果要SQL分散在不同的代码文件中，从mysql一直到Oracle，可能是又是一个脏活。

  我对Ibatis进行了改造，自动加上分页代码，开发人员就不用管分页，由Ibatis得到SQL后，自动根据不同的数据，加上不同的分页机制。

  如mysql分页，就是在select 语句后面加上limit , SQLserver的分页，则是根据rowNum分页，等等。

 

3)struts的规划和应用

  struts是面向前端请求的处理框架，我们首先要归纳前端的功能请求，并分类，以此作为规划struts的依据。

  首先GPS的请求，主要有:登录，实时数据，报警，报表，基础信息增删改，报表分页查询，地图持久化操作请求，终端指令下发，

  在设计Action的时候，尽量以单元形成进行规划，对XML文件按功能模块划分。对URL命名形成标准规范。

购买GPS平台源码，联系我speed.zheng@gmail.com

4)quartz定时器框架

  很多GPS平台，大量使用了存储过程了，我见过有家公司维护100多个存储过程，太壮观了，我都不知道如果写存储过程的人走了，接手的人是不是要哭了。连分页也要用存储过程，估计负责的人很擅长存储过程。但他只顾自己爽了，即使不考虑移植，也得考虑维护、调试、SVN库提交、单元测试等等。

  其实代码中，可以做到零存储过程，对于报表统计类的，可以完全采用定时统计的方式进行。如上线率，可以半小时统计一次，也可以一个小时统计一次，完全不用写存储过程，通过漫长的计算，对大量的数据进行聚合运算，得出一个结果来。

  定时统计是一种规划收到，通过对未来数据增长量的估计，来设计现阶段的数据生成行为，通过规划来避免对数据库大开大合的查询。当车辆数和数据量达到一定层级的时候，就显示出定时统计的威力了。比如报警次数统计，如果允许用户统计任意时间端的报警次数，虽然很灵活，也满足用户需求，但是一个大型GPS平台，每月要产生出巨量的垃圾报警。一个报警统计的SQL查询或存储过程查询就把数据库的CPU推向高潮。

5) Spring框架

  作为JAVA开发的人，就不用说了，是一个容器，一个粘合剂，将各个层的功能，通过配置和依赖注入，达到粘合的作用。

  作为GPS平台，我们推崇的是面向服务开发，所以不可避免的要使用RMI，而Spring很容易将一个Service类，转换成一个远程RMI调用接口，开通接口服务。

  有了Spring框架，我们就可以专心致志的规划我们的服务了，而不用关心是远程调用还是本地调用的底层机制了。

  同时Spring的面向接口开发，天然不自觉的是我们的程序具备了初级的可扩展性。

  如地图API服务，我们可能用Java通过http请求后台调用百度地图的API来逆向地理解析，也可以用高德或谷歌的，那我们就规划一个LocationService, 定义这个服务提供加偏、地址转换等功能。至于服务是如何实现的，调用者不用关心。  

  当然了在Spring中，也非常享受工厂模式的灵活运用，通过在配置文件中配置。我们可以根据调用参数不同，生产出不同的接口类，如一个终端数据包上来，可能是部标808协议，也可能是DB44，也可能厂商自定义协议，我们可以根据spring的配置，调用不同的解析插件来进行解析。让整个代码结构都显得简洁有气质。