在當(dāng)前很多的GPS平臺當(dāng)中，有很多是基于asp.NET+siverlight開發(fā)的遺留項(xiàng)目，代碼混亂而又難以維護(hù)，各種耦合和關(guān)聯(lián)，要命的是界面也沒見到比Javascript做的控件有多好看，隨著需求的增多，平臺已經(jīng)臃腫不堪。

設(shè)計基于.NET的GPS部標(biāo)平臺，我們堅定不移的選擇了基于JQUERY+Asp.NET MVC來作為前端交互和后臺處理的框架。選用一個靈活的腳手架，同時團(tuán)隊(duì)又能掌握這個腳手架為團(tuán)隊(duì)所用。

對于一個web應(yīng)用項(xiàng)目，基于MVC的框架，前面文章提到過，最大的優(yōu)點(diǎn)就是結(jié)構(gòu)清晰，強(qiáng)制性的將繁亂的頁面，請求，后臺處理邏輯，劃分成MVC三層結(jié)構(gòu)，一層一層的做開發(fā)，一層一層的維護(hù)，同時層也不多，適可而止。通過MVC，高手和低手，在開發(fā)的初期基本上站在一個起跑線上，這個我認(rèn)為很重要，特別是團(tuán)隊(duì)開發(fā)和維護(hù)，團(tuán)隊(duì)中的人開發(fā)水平各不一樣，對于架構(gòu)設(shè)計這種抽象到家的技術(shù)，理解也各不一樣，每次項(xiàng)目啟動的時候，都有各種各樣的爭論，都覺得自己是架構(gòu)師，這是很要命的，很多人認(rèn)為設(shè)計可以讓開發(fā)效率更高，代碼更容易擴(kuò)展，后期更容易維護(hù)，性能更好更穩(wěn)定，更易用。但糅合各種意見、評審、討論、妥協(xié)的設(shè)計無一例外最終卻走向反面。

很多人都是從asp.net web form過來的，對這個很不以為然，其實(shí)正是這種溫吞水煮青蛙的開發(fā)技術(shù)，造成了部分人員留下了慘痛的后遺癥，主要表現(xiàn)在：

1.首先就是學(xué)習(xí)能力差，其實(shí)也不是沒學(xué)習(xí)能力，主要是看見新東西沒興趣，沒動力，這個要命的缺點(diǎn)造成了后面的缺點(diǎn)

2.大量依賴于服務(wù)器端控件，對于前端的javascript以及js框架，css+div布局等技術(shù)，掌握很少，造成前端開發(fā)效率低下，出一點(diǎn)問題就調(diào)試?yán)习胩臁＜夹g(shù)太單一，在職場上可以說沒有競爭力和吸引力。

3.寫代碼時，各種隨意，有的不分層，各種邏輯都一股腦揉進(jìn)UI，有的分層，但往往受PetStore的毒害，搞了很多層，畫虎不成反類犬，為了重用，一層套一層，連環(huán)調(diào)用，看代碼，需要運(yùn)行打斷點(diǎn)，一層一層往下看，就像進(jìn)入十八層地獄，最后終于到底看到了SQL。代碼中特別喜歡直接寫SQL，各種insert,select滿天飛，各種ifelse,各種重復(fù)，這些項(xiàng)目中代碼量最大的地方，往往就在這個地方，而這個地方是最沒技術(shù)含量的。

很多開發(fā)者經(jīng)歷過各種苦難，都想在下一次開發(fā)中不要這樣，但如果出于對未來變數(shù)的恐懼而總是追求各種莫須有以后也從未發(fā)生過的擴(kuò)展，在項(xiàng)目的初期就臆想各種高性能，高批量，大規(guī)模，因?yàn)槌橄蠖敫鞣N抽象，因?yàn)榧軜?gòu)設(shè)計就設(shè)計一個復(fù)雜的架構(gòu)。那么開發(fā)者的宿命就是不斷的輪回。

對于一個GPS的Web平臺，設(shè)計的重心就是要回歸到結(jié)構(gòu)清晰，先談結(jié)構(gòu)，再談架構(gòu)，結(jié)構(gòu)是扁平化，清晰化，一堆亂如麻的東西我們的目標(biāo)就是消除臃腫，歸類，分清楚，需用用的時候找得到，簡潔化;架構(gòu)是立體化，也是復(fù)雜化，多個子系統(tǒng)，多個接口，多個服務(wù)，多種面向服務(wù)的調(diào)用。

我們在設(shè)計的時候，總是先在文檔中牛掰的寫到設(shè)計原則與目標(biāo)，但是往后面看，發(fā)現(xiàn)我們設(shè)計和開發(fā)的東西和我們寫的原則沒有一點(diǎn)毛關(guān)系。所以要想設(shè)計好，就要想清楚你得設(shè)計原則是不是有利于你的設(shè)計目標(biāo)，你做的東西是不是奔著你設(shè)計的目標(biāo)去了。

我們的設(shè)計原則就是追求結(jié)構(gòu)清晰，說白了就是追求單一職責(zé)原則的最大化，無論前端還是后臺。一個蘿卜一個坑，一個蘿卜坑里面就是一個蘿卜，不能里面放一顆白菜。

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

2.追求命名具體而規(guī)范，特別是前端。看到命名，能知道功能，最好就像倉庫的標(biāo)簽。看到名字，就知道是干什么的，在哪里放著，也知道應(yīng)該在哪里放。

3.減少抽象，?C#和java放棄了c++的多重繼承，就是因?yàn)閺?fù)雜度的增加，得不償失。你要理解這個，多重接口你也不愿意用，看者都暈。我在看Ibatis的源碼的時候，一個類后面繼承了五六個接口，看到一個接口定義的變量后，如果不打上斷點(diǎn)，都找不到實(shí)現(xiàn)類在哪里。很多代碼都是如此，等項(xiàng)目結(jié)束了，回頭看，好聽點(diǎn)就是層層調(diào)用，通俗地說就是大方法里套小方法，小方法里調(diào)鄰居方法，調(diào)的多了，復(fù)雜度就上來了，一個方法多個地方調(diào)用、重寫(override)，等你想修改的時候，影響一大片。

4.追求單一職責(zé)，一個功能，或者邏輯緊密相關(guān)的功能，歸結(jié)到一個類中。單一職責(zé)原則中對職責(zé)的理解各不一樣，同時也可大可小，小到一個功能點(diǎn)，大到一個功能模塊，子系統(tǒng)。這也是要求我們要把這個原則從小到大，從底向上，從前到后，貫穿始終。單一職責(zé)原則和命名規(guī)范結(jié)合一起，有利于維護(hù)結(jié)構(gòu)的清晰。比如你看到GPS平臺的車輛樹菜單，想進(jìn)入到j(luò)s代碼中調(diào)試，由于我們把關(guān)于車輛樹的代碼都寫入到一個獨(dú)立的vehicleTree.js中，那就直接找到了。看到前端代碼后，我們想看看后端是怎么是怎么處理ajax 請求的，由于是采用MVC框架，處理前端請求的都是編寫對應(yīng)的controller類，我們命名是VehicelTreeController.cs文件，這樣我們也快速的定位到代碼，也明白了從前到后的調(diào)用路徑和結(jié)構(gòu)。同時這個里面的代碼就是寫的再亂，也不會傳染給其他代碼，所謂的傳染就是一段復(fù)雜難理解、難調(diào)試、難維護(hù)的代碼，不會造成其他文件或功能的代碼難以理解、調(diào)試和維護(hù)。

5.減少裝逼。在項(xiàng)目的前期，各種裝逼，什么需求分析，概念設(shè)計，架構(gòu)設(shè)計，UML等等時間殺手，裝逼的成本高昂，代價慘重。我們追求的結(jié)構(gòu)就是扁平化，不需要你裝逼，整各種傻逼UML圖，也不需要你寫各種自己都不會去看的文檔。一個excel就夠了。

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

?

?

當(dāng)然一個復(fù)雜的部標(biāo)平臺，不僅僅是web，還要部標(biāo)808和809GPS服務(wù)器等，各個子系統(tǒng)之間也需要互聯(lián)互通，壓力最大的在于GPS服務(wù)器, 參見我前面的文章：

GPS部標(biāo)監(jiān)控平臺的架構(gòu)設(shè)計(八)-基于WCF的平臺數(shù)據(jù)通信設(shè)計

部標(biāo)808協(xié)議模擬終端的設(shè)計和開發(fā)

1)808GPS服務(wù)器，采用交通部的部標(biāo)808協(xié)議，負(fù)責(zé)與終端的數(shù)據(jù)接收、指令下發(fā);?參見：基于部標(biāo)JT/T 808協(xié)議及數(shù)據(jù)格式的GPS服務(wù)器

2)809轉(zhuǎn)發(fā)服務(wù)器，采用交通部的部標(biāo)809協(xié)議，作為企業(yè)下級平臺，負(fù)責(zé)轉(zhuǎn)發(fā)GPS數(shù)據(jù)到政府平臺的服務(wù)器;參見:基于JT/T809-2011的(已過檢)GPS平臺數(shù)據(jù)交換及轉(zhuǎn)發(fā)服務(wù)器

最后的工程：

如需購買GPS平臺源碼+文檔+服務(wù)，可以聯(lián)系我2379423771@qq.com。

?

轉(zhuǎn)載于:https://www.cnblogs.com/productivity/p/4405600.html

總結(jié)

以上是生活随笔為你收集整理的GPS部标平台的架构设计(十)-基于Asp.NET MVC构建GPS部标平台的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。