廢話少說，咱們如今構建基於BS網頁Web模式的部標GPS監控平臺，基於主流的J2EE三層模型，主要的技術選型以下：
1.基礎容器框架 spring4
2.Web框架 Springmvc4
3.ORM實體與關係數據庫映射框架 hibernate4
4.SQL查詢框架 mybatis3
5.單元測試 junit4
6.日誌 log4j
7.定時任務框架Quartz
系統運行環境：tomcat7+ 、JDK7+、MySql 5.7/ SQSERVER2005/Oracle9
GPS監控的web平臺對技術的要求以下：
1.實時監控和部標808協議的幾十種終端指令的上傳下達，百度地圖車輛位置監控，地圖操做等功能須要頻發的對服務器發送基於ajax的request，返回json數據，基本上是重度使用ajax請求和Json傳輸。
2.Web服務器須要應對網頁客戶端重度的request請求，性能要求較高，在mvc框架開發的時候，必定要避免內存泄漏，由於在頻繁的request請求調用之下，小小的內存泄漏，會一點一點積累，直至耗掉tomcat的內存。
3.安全性上，框架至少要可以防護CSRF、XSS和SQL注入攻擊
Web框架咱們採用sprngMVC4， 主要的考慮以下：
1.全註解環境，採用springmvc4，替xml配置，避免掉了一大堆的xml配置，對應URL的映射和request參數的映射直接在方法中經過註解配置；
2.spring mvc是基於方法的設計，controller是單例模式，而sturts是基於類，每次發一次請求都會實例一個action，每一個action都會被注入屬性，而spring基於方法，粒度更細，性能上更高一籌；
3.SpringMVC框架的安全性上要高於struts，詳見百度搜索。
數據庫ORM的框架要求以下：
1.可以比較靈活的適應主流的數據庫，如mysql, mssqlserver, oracle等，如今的開發團隊和開發人員在開發的時候，幾乎沒有人關注這個問題，基本都是在一個數據庫上吊死，而做爲一個平臺的開發，爲應對不一樣的客戶要求，團隊的開發力量有限，不能一個數據庫一個版本，這樣開發和維護、升級、測試成本就急速的升高，因此咱們追求的是一下幾個原則：
1）不用存儲過程和觸發器；
不少開發團隊都是重度的存儲過程和觸發器的使用者，連簡單的查詢分頁都要用存儲過程，一旦開發人員離職，這些存儲過程和觸發器都像天書同樣，難以維護，通常咱們的代碼都是在SVN基於配置庫進行版本管理，而存儲過程和觸發器卻脫離這些以外，存儲過程和觸發器若是有bug出現問題，在生產環境上，很難進行跟蹤，web容器的日誌記錄只能跟蹤到java代碼級別，剩下就須要DBA來配合了。
2）使用Hibernate4 框架，實體類和數據庫的映射都在類和屬性方法上完成；基於Hibernate的配置就能夠輕鬆切換到其餘數據庫。
3）採用採用Mybatis的物理分頁插件，經過攔截器的方式，在開發人員編寫的SQL上進行攔截，並自動包裝上各個數據庫的物理分頁代碼，能夠支持多個主流數據庫的物理分頁查詢方法。
4）採用mybatis和log4j，能夠很方便的打印SQL日誌，方便調試跟蹤。
基於Maven構建多模塊項目工程，打造乾淨的依賴庫
咱們在開發GPS監控平臺的時候，通常都是基於業務功能和職責，將業務分爲多個模塊，各個模塊之間相互獨立，每一個模塊能夠獨立運行或者做爲獨立的公共類庫被其餘模塊所依賴如Dao、Service等。
實際上一個部標GPS監控平臺，裏面包含了多個業務功能模塊，如部標808GPS服務器，web網頁客戶端，809轉發服務器，移動API，位置服務，計算服務等等。
因爲多個模塊，都須要依賴這些開發框架，而開源框架又有各自的依賴的jar包，他們的版本搭配很是關鍵，例如springmvc4用的jackson框架是2.1， springmvc3 用的jackjson框架是1.x版本，你若是搭配錯了，項目運行不起來了。再好比spring和mybatis, hibernate之間的無縫結合，雖然是互相搭配，但你若是用的版本不一致，也會形成項目出錯。將來咱們想升級某個框架，好比從spring4升級到spring5,也是否是單純的只升級spring4, 而是要考慮hibernate, mybatis等框架的聯動升級。
因此採用Maven來提供工程的中央倉庫，全部的子模塊共享一個POM文件，避免各個子模塊各自重複依賴一大堆jar包。Maven的多模塊其實就是按照層級的管理構建，項目包含一個pom.xml文件和若干個模塊，每一個模塊有一個單獨的pom.xml文件，經過pom的依賴和繼承關係來構建項目層次。一旦建好之後，就能夠終身享用，工做量會大大下降，jar包版本不一致的形成的項目風險會大大下降。
而整個項目工程的拷貝複製就更加簡單，裏面再也不有大量的jar包，開發人員只需從配置庫上更新最新的代碼後，配置庫中再也不有大量的開源框架jar包，而是從Maven中央倉庫中自動更新。創建工程的時候，直接選擇導入Maven工程，一鍵將全部的模塊導入到新的workspace當中，很是方便。
購買GPS平臺或GPS監控系統源碼，聯繫我2379423771@qq.com
工程目錄和包命名規範
我如今根據Spring的註釋，包的命名，固然這首先創建在你對三層架構的熟悉上。
com.ltmonitor.jt808.app 808服務器應用程序
com.ltmonitor.jt809.app 808服務器應用程序
com.ltmonitor.web.vo 用於web頁面傳遞的對象
com.ltmonitor.service.vo 用於服務傳遞的對象
com.ltmonitor.controller MVC中的控制,Spring的註釋@controller
com.ltmonitor.controller.map 地圖表現層
com.ltmonitor.controller.terminalcommand 終端指令
com.ltmonitor.entity 實體類
com.ltmonitor.entity.jt808 專用於808gps服務器的實體類
com.ltmonitor.entity.jt809 專用於809服務器的實體類
com.ltmonitor.dao Dao層
com.ltmonitor.servce service層
com.ltmonitor.server gps服務器層
。。。
。。。。。
。。。。
完備的開發手冊能夠幫助開發人員理解整個平臺。
數據字典：
本版本是2015-2016年近一年推出的穩定版本，相對於原來的2014年研發的舊版的struts版本，從性能和功能上有了較大的提高，融合了大量客戶的需求意見，特色：
1）SpringMVC版本已經替代struts成爲主流框架，在安全和性能上有很大的提高，struts開源框架有安全隱患，容易受到攻擊，公網服務器能夠被黑客攻破得到管理員權限。
2）採用Netty框架替代原有的Mina框架，在服務器的併發性能上有了大幅提高，普通服務器單進程能夠支撐到3萬臺終端；部標808服務器所支持的部標協議，舊版只支持jt/t 808 2011版本的協議，新版本全面支持jt/t 808 2013版本的協議，如定時拍照等新特性，增長了808協議數據實時轉發的特性。
3）能夠接收第三方的轉發的數據，因爲不少GPS平臺所得到的數據都是從第三方平臺而來，並不能獲得一手的GPS終端數據，809模塊增長了809政府運管服務器，用來接收第三方轉發而來的數據。
3）採用Mybatis替代舊版本中已經淘汰的Ibatis框架，經過Mybatis的查詢分頁插件，能夠很方便的支撐各類數據庫的分頁查詢，代碼能夠支持Mysql, Sqlserver, 和Oracle三種數據庫，利用Mybatis的批量插入特性，大幅提高了GPS數據入庫的性能；
4）地圖部分作了較大的優化，統一地圖接口，支持百度、高德和四維三種地圖；
5）新版本是基於saas的多租戶架構設計，充分支持多公司，多集團，多代理的組織架構模式，不一樣企業實體的數據、權限進行徹底的隔離，能夠單獨爲每一個企業分配企業管理員，企業管理員在本身的企業實體內，能夠單獨分配角色權限，創建部門和車隊；
6）Spring框架從舊版的2.5升級到Spring4, 從原來的全xml配置，利用Spring4的註解特性，大幅削減了系統的xml配置，系統部署和配置更加方便，維護更加容易；
7) SpringMVC4集成WebSocket，基於Websocket進行報警推送，大大提升報警推送的效率。
參見：基於Websocket+SpringMVC4推送部標Jt808終端報警
8）對原有的代碼作了大量的優化，性能作了較大的提高，代碼進行了充分的重構，增長了大量的註釋，設計文檔進行了重寫；
舊版的基於struts2技術框架的平臺仍然在銷售，參見基於Struts+Spring+Hibernate+Ibatis+Quartz+Mina框架構建部標監控平臺
.NET平臺，參見：基於Asp.NET MVC構建GPS部標平臺
支持百度高德地圖聚合
支持海量車輛在地圖上的位置顯示和移動，經過顏色區分車輛的在線狀態和停車行駛狀態