GPS部標平臺的架構設計(三) 基於struts+spring+hibernate+ibatis+quartz+mina框架開發GPS平臺

注意，此版本是2014年研發的基於Spring2.5和Struts2的版本，此版本的源碼仍然銷售，但已再也不提供源碼升級的服務，由於目前咱們開發的主流新版本是2015-2016年近一年推出的基於spring4+springMVC4+mybatis3+Hibernate4+junit4框架構建高性能企業級的部標GPS監控平臺，相對於原來的2014年研發的舊版的struts版本，從性能和功能上有了較大的提高，融合了大量客戶的需求意見，相對於Struts版本，主要的特色，請點擊文章詳細閱讀和比對：

基於Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架構建高性能企業級的部標GPS監控平臺

 在開發一個基於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平臺或GPS監控系統源碼，聯繫我 2379423771@qq.com

.NET平臺，參見： 基於Asp.NET MVC構建GPS部標平臺

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的配置，調用不一樣的解析插件來進行解析。讓整個代碼結構都顯得簡潔有氣質。

基於SpringMVC框架技術的GPS平臺，能夠參見：基於Spring4+SpringMVC4+Mybatis4+Hibernate4+Junit4框架構建高性能企業級的部標GPS監控平臺

 

具體功能說明，參見：GPS部標監控平臺的功能設計(一)-功能列表

 

主界面:

 

 

2.實時車輛狀態樹

 

 

3.豐富的地圖功能

  1）支持百度、高德和四維三種地圖，其中，高德地圖和四維地圖是部標檢測時要求必需要選用其一的地圖；

  

  2)  圓形、矩形、多邊形電子圍欄標註，線路支持分段限速；

  3）車輛地圖圖標支持後臺風格選擇，目前支持Arrow和Car兩種模式，根據車輛的行駛狀態，變換成不一樣的顏色；

  

  4) 基於模版定製車輛信息窗口

 

4.充分支持jt/t808 2013協議中的所有協議棧

 

5.豐富的報表支持

 

 

6.強大的系統配置功能，經過系統配置，能夠靈活適用於各類場景的支持。

 

7。基於saas模式的平臺架構，支持多企業，多部門的架構，企業和部門能夠獨立設定角色。