GPS部标平台的架构设计(三) 基于struts+spring+hibernate+ibatis+quartz+mina框架开发GPS平台

注意,此版本是2014年研发的基于Spring2.5和Struts2的版本,此版本的源码仍然销售,但已不再提供源码升级的服务,因为目前我们开发的主流新版本是2015-2016年近一年推出的基于spring4+springMVC4+mybatis3+Hibernate4+junit4框架构建高性能企业级的部标GPS监控平台,相对于原来的2014年研发的旧版的struts版本,从性能和功能上有了较大的提升,融合了大量客户的需求意见,相对于Struts版本,主要的特点,请点击文章详细阅读和比对:
在开发一个基于Java的、BS架构的GPS平台的时候,我们总是要花费很多心思去选择框架,在此基础上进行封装提供易用的功能,来作为我们快速开发的平台。
有的公司有积累,可能在此上面花费的时间比较少,有的没积累,可能为了选择什么样的框架,为了优缺点争论不休,耽误个把月时间都有可能。
我希望在此给出一个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部标平台的架构设计(三) 基于struts+spring+hibernate+ibatis+quartz+mina框架开发GPS平台
 
购买GPS平台源码,联系我2379423771@qq.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的配置,调用不同的解析插件来进行解析。让整个代码结构都显得简洁有气质。
GPS部标平台的架构设计(三) 基于struts+spring+hibernate+ibatis+quartz+mina框架开发GPS平台
上一篇:JS 获取各个宽度和高度


下一篇:jQueryPrint 的简单使用