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

2019-11-17 02:03:53

字體：大中小

來源：轉載

供稿：網友

GPS部標平臺的架構設計(十)-基于 asp.net MVC構建GPS部標平臺

2015-04-09 00:24 by 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就夠了。