GPS部標平臺的架構設計(十)-基於Asp.NET MVC構建GPS部標平臺

在當前不少的GPS平臺當中，有不少是基於asp.NET+siverlight開發的遺留項目，代碼混亂而又難以維護，各類耦合和關聯，要命的是界面也沒見到比Javascript作的控件有多好看，隨着需求的增多，平臺已經臃腫不堪。

設計基於.NET的GPS部標平臺，咱們堅決不移的選擇了基於JQUERY+Asp.NET MVC來做爲前端交互和後臺處理的框架。選用一個靈活的腳手架，同時團隊又能掌握這個腳手架爲團隊所用。

對於一個web應用項目，基於MVC的框架，前面文章提到過，最大的優勢就是結構清晰，強制性的將繁亂的頁面，請求，後臺處理邏輯，劃分紅MVC三層結構，一層一層的作開發，一層一層的維護，同時層也很少，適可而止。經過MVC，高手和低手，在開發的初期基本上站在一個起跑線上，這個我認爲很重要，特別是團隊開發和維護，團隊中的人開發水平各不同，對於架構設計這種抽象到家的技術，理解也各不同，每次項目啓動的時候，都有各類各樣的爭論，都以爲本身是架構師，這是很要命的，不少人認爲設計可讓開發效率更高，代碼更容易擴展，後期更容易維護，性能更好更穩定，更易用。但糅合各類意見、評審、討論、妥協的設計無一例外最終卻走向反面。

不少人都是從asp.net web form過來的，對這個很不覺得然，其實正是這種溫吞水煮青蛙的開發技術，形成了部分人員留下了慘痛的後遺症，主要表如今：

1.首先就是學習能力差，其實也不是沒學習能力，主要是看見新東西沒興趣，沒動力，這個要命的缺點形成了後面的缺點

2.大量依賴於服務器端控件，對於前端的javascript以及js框架，css+div佈局等技術，掌握不多，形成前端開發效率低下，出一點問題就調試老半天。技術太單一，在職場上能夠說沒有競爭力和吸引力。

3.寫代碼時，各類隨意，有的不分層，各類邏輯都一股腦揉進UI，有的分層，但每每受PetStore的毒害，搞了不少層，畫虎不成反類犬，爲了重用，一層套一層，連環調用，看代碼，須要運行打斷點，一層一層往下看，就像進入十八層地獄，最後終於到底看到了SQL。代碼中特別喜歡直接寫SQL，各類insert,select滿天飛，各類ifelse,各類重複，這些項目中代碼量最大的地方，每每就在這個地方，而這個地方是最沒技術含量的。

不少開發者經歷過各類苦難，都想在下一次開發中不要這樣，但若是出於對將來變數的恐懼而老是追求各類莫須有之後也從未發生過的擴展，在項目的初期就臆想各類高性能，高批量，大規模，由於抽象而引入各類抽象，由於架構設計就設計一個複雜的架構。那麼開發者的宿命就是不斷的輪迴。

對於一個GPS的Web平臺，設計的重心就是要回歸到結構清晰，先談結構，再談架構，結構是扁平化，清晰化，一堆亂如麻的東西咱們的目標就是消除臃腫，歸類，分清楚，需用用的時候找獲得，簡潔化;架構是立體化，也是複雜化，多個子系統，多個接口，多個服務，多種面向服務的調用。

咱們在設計的時候，老是先在文檔中牛掰的寫到設計原則與目標，可是日後面看，發現咱們設計和開發的東西和咱們寫的原則沒有一點毛關係。因此要想設計好，就要想清楚你得設計原則是否是有利於你的設計目標，你作的東西是否是奔着你設計的目標去了。

咱們的設計原則就是追求結構清晰，說白了就是追求單一職責原則的最大化，不管前端仍是後臺。一個蘿蔔一個坑，一個蘿蔔坑裏面就是一個蘿蔔，不能裏面放一顆白菜。

1.MVC，三層夠用，再多打屁屁。

2.追求命名具體而規範，特別是前端。看到命名，能知道功能，最好就像倉庫的標籤。看到名字，就知道是幹什麼的，在哪裏放着，也知道應該在哪裏放。

3.減小抽象， C#和java放棄了c++的多重繼承，就是由於複雜度的增長，得不償失。你要理解這個，多重接口你也不肯意用，看者都暈。我在看Ibatis的源碼的時候，一個類後面繼承了五六個接口，看到一個接口定義的變量後，若是不打上斷點，都找不到實現類在哪裏。不少代碼都是如此，等項目結束了，回頭看，好聽點就是層層調用，通俗地說就是大方法裏套小方法，小方法裏調鄰居方法，調的多了，複雜度就上來了，一個方法多個地方調用、重寫(override)，等你想修改的時候，影響一大片。

4.追求單一職責，一個功能，或者邏輯緊密相關的功能，歸結到一個類中。單一職責原則中對職責的理解各不同，同時也可大可小，小到一個功能點，大到一個功能模塊，子系統。這也是要求咱們要把這個原則從小到大，從底向上，從前到後，貫穿始終。單一職責原則和命名規範結合一塊兒，有利於維護結構的清晰。好比你看到GPS平臺的車輛樹菜單，想進入到js代碼中調試，因爲咱們把關於車輛樹的代碼都寫入到一個獨立的vehicleTree.js中，那就直接找到了。看到前端代碼後，咱們想看看後端是怎麼是怎麼處理ajax 請求的，因爲是採用MVC框架，處理前端請求的都是編寫對應的controller類，咱們命名是VehicelTreeController.cs文件，這樣咱們也快速的定位到代碼，也明白了從前到後的調用路徑和結構。同時這個裏面的代碼就是寫的再亂，也不會傳染給其餘代碼，所謂的傳染就是一段複雜難理解、難調試、難維護的代碼，不會形成其餘文件或功能的代碼難以理解、調試和維護。

5.減小裝逼。在項目的前期，各類裝逼，什麼需求分析，概念設計，架構設計，UML等等時間殺手，裝逼的成本高昂，代價慘重。咱們追求的結構就是扁平化，不須要你裝逼，整各類傻逼UML圖，也不須要你寫各類本身都不會去看的文檔。一個excel就夠了。

功能描述	js類	controller類	service類
車輛樹	vehicleTree.js
主菜單	mainMenu.js

 

 

固然一個複雜的部標平臺，不只僅是web，還要部標808和809GPS服務器等，各個子系統之間也須要互聯互通，壓力最大的在於GPS服務器, 參見我前面的文章：

GPS部標監控平臺的架構設計(八)-基於WCF的平臺數據通訊設計

部標808協議模擬終端的設計和開發

1)808GPS服務器，採用交通部的部標808協議，負責與終端的數據接收、指令下發; 參見：基於部標JT/T 808協議及數據格式的GPS服務器

2)809轉發服務器，採用交通部的部標809協議，做爲企業下級平臺，負責轉發GPS數據到政府平臺的服務器;參見:基於JT/T809-2011的(已過檢)GPS平臺數據交換及轉發服務器

最後的工程：

如需購買GPS平臺源碼+文檔+服務，能夠聯繫我2379423771@qq.com。