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就够了。