Architecture design of GPS Platform (10)-building a GPS platform based on ASP. NET MVC

In many of the current GPS platforms, there are a lot of legacy projects based on Asp.net+siverlight development, the code is confusing and difficult to maintain, various couplings and associations, the interface is not seen much better than the control of JavaScript, with the increase in demand, The platform is bloated.

Design based on. NET of the GPS platform, we have steadfastly chosen to be based on jquery+asp.net MVC as the front-end interaction and background processing framework. Choose a flexible scaffold, and the team can master the scaffold for the team.

For a Web application project, based on the MVC framework, the previous article mentioned, the biggest advantage is the structure of clear, mandatory Fanluan page, request, background processing logic, divided into MVC three layer structure, one layer of the development, one layer of maintenance, and the layer is not much, enough. Through the MVC, master and low hand, in the early stages of development basically stood at a starting line, this I think is very important, especially team development and maintenance, the team's development level is different, for the architectural design of this abstraction home technology, understanding is different, every time the project started, there are all kinds of controversy, All feel that they are architects, this is very deadly, many people think that design can make development more efficient, code easier to expand, later easier to maintain, better performance, more stable, more easy to use. But the design of a mix of opinions, reviews, discussions, compromises, without exception, eventually goes to the opposite end.

A lot of people are from the ASP. NET Web Form come over, to this very disagree, in fact it is this warm swallow boiled frog development technology, caused some people left a painful sequela, mainly manifested in:

1. The first is the poor learning ability, in fact, is not the ability to learn, mainly to see new things no interest, no motivation, this deadly shortcomings caused by the shortcomings of the back

2. Rely heavily on server-side controls, for the front-end JavaScript and JS framework, CSS+DIV layout and other technologies, little grasp, resulting in the front-end development efficiency is low, a little problem on the debug long time. Technology is too single, in the workplace can be said to be uncompetitive and attractive.

3. Write code, a variety of random, some non-layered, all kinds of logic is a brain rub into the UI, and some layered, but often by petstore poison, make a lot of layers, painting tiger is not anti-class dog, in order to reuse, a layer of a layer, serial calls, see Code, need to run break point, a layer down, It's like entering a 18-story hell and finally finally seeing SQL. Code in particular like direct write SQL, a variety of insert,select flying, all kinds of ifelse, all kinds of repetition, these projects in the most code of the place, often in this place, and this place is the least technical content.

Many developers have experienced a variety of hardships and want to avoid this in the next development, but if you are always pursuing a variety of extensions that have never happened since then, in the early stages of the project, imagine high-performance, high-volume, large-scale, abstract, Because architecture design is designed to be a complex architecture. Then the developer's fate is the constant cycle.

For a GPS web platform, the design of the center of gravity is to return to the structure of clear, first talk about structure, then talk about architecture, structure is flat, clear, a bunch of disorderly such as of things our goal is to eliminate bloated, classified, divided clearly, need to use the time to find, concise; architecture is three-dimensional, but also complex, multiple subsystems , multiple interfaces, multiple services, and multiple service-oriented calls.

When we design, we always first write about the design principles and goals in the document, but looking back, we found that the things we designed and developed were not related to the principles we wrote. So if you want to design, you have to figure out whether your design principles are conducive to your design goals, and what you are doing is running the target of your design.

Our design principle is the pursuit of a clear structure, white is the pursuit of the principle of single responsibility to maximize, whether front-end or backstage. A radish a pit, a turnip pit inside is a radish, can not put a cabbage inside.

1.MVC, three floor enough, and more fart.

2. The pursuit of naming specific and normative, especially the front end. See the name, can know the function, the best is like a warehouse label. When you see a name, you know what it is, where you put it, and where you should put it.

3. Reduce abstraction, C # and Java abandon the multiple inheritance of C + +, because of the increase in complexity, not worth the candle. You have to understand this, multi-interface you do not want to use, the eyes are dizzy. I was looking at the source of Ibatis, a class after inheriting five or six interfaces, see an interface defined variables, if not hit the breakpoint, can not find the implementation of the class where. A lot of code is so, and so the end of the project, looking back, nice point is the layer of calls, popularly said is the big way to set a small method, small method in the neighbor method, adjust the more, the complexity comes up, a method multiple places call, rewrite (override), and so you want to modify the time, affect a large.

4. The pursuit of a single function, a function, or logically closely related functions, boils down to a class. The principle of single responsibility in the understanding of responsibilities are different, but also can be small, small to a function point, large to a functional module, subsystem. This also requires us to take this principle from small to large, from the bottom up, from the past to the back, through always. The combination of a single responsibility principle and a naming convention facilitates the maintenance of a clear structure. For example, you see the GPS platform of the vehicle tree menu, want to enter into the JS code debugging, because we have to write about the vehicle tree code in a separate vehicletree.js, then directly found. After seeing the front-end code, we want to see how the backend is handling AJAX requests, because the MVC framework is used to process the front-end requests to write the corresponding controller class, We named the VehicelTreeController.cs file, so we quickly navigate to the code and understand the path and structure of the call from the front to the back. At the same time the code inside this is to write the chaos, and will not infect other code, the so-called infection is a complex difficult to understand, difficult to debug, difficult to maintain code, will not cause other files or functions of the code difficult to understand, debugging and maintenance.

5. Reduce the loading force. In the early stages of the project, all kinds of loading force, what needs analysis, conceptual design, architecture design, UML and so on time killer, loading forcing the cost of high, costly. Our pursuit of the structure is flat, do not need you to install force, the whole variety of silly uml diagram, do not need you to write all kinds of documents you will not see. An Excel is enough.

Function description	JS class	Controller class	Service class
Vehicle Tree	Vehicletree.js
Main Menu	Mainmenu.js

Of course a complex platform for the ministry, not just the web, but also the Ministry of 808 and 809GPS servers, and other subsystems also need to interconnect, the most pressure is the GPS server, see my previous article:

Architecture design of GPS monitoring platform (eight)-design of platform data communication based on WCF

The final project:

Architecture design of the GPS platform (10)-building a GPS platform based on ASP. NET MVC