MVC design mode of ASP. NET

When developers hear the word "design pattern", they generally think of two scenarios. A group of developers are discussing many creative ideas. They are in a meeting but are not coding. Another group of people can work out the right plan to ensure that the system can be developed successfully and the code can be reused.

The reality is generally in the middle of the two. Structural designers and system designers should look for repetitive patterns when designing solutions for their companies. However, the mode is only a guide for developing robust and reusable code. The structure designer cannot design a solution structure too much, because regular delivery is required.

Web applications are the main victims of excessive design of system structures. Because most web applications are used to browse data, they are designed to ensure that the data display speed can keep up with the data update speed. In many cases, building a complex, multi-level architecture does not meet the needs of users or developers. Let's take a look at a simple example of developing. NET web applications:

Use ASP. NET to implement a classic design model

Smalltalk, the earliest object-oriented programming language, provides developers with a platform for rapid development of object-oriented systems. The classic model, view, and controller (MVC) design pattern is developed from this research and is still used as a reference model. The model stores the data displayed by the view and controlled by the Controller. View sends the output to the user, and the Controller is responsible for reflecting the user's actions and updating the model accordingly.

ASP. NET provides a similar environment for implementing this classic design mode. Developers can develop user interfaces on the ASPX page to implement views. The controller function is implemented in the Logic Function Code (Code-behind) file (FOO. aspx. VB or Foo. aspx. CS.

Implementing this design in. NET provides a two-tier system, which has obvious advantages over the classic ASP structure. Separating user views from Action controllers improves code reusability. Separating data (model) from the Controller allows you to design a system that is irrelevant to the data stored in the background.

If the design is correct, a system based on the MVC design pattern will not know or care whether the data provided to the model component is stored in the SQL server or Oracle database, or stored in a group of XML documents.

Many people will say that developers can easily implement this mode using ASP pages and COM objects. However, the fact is that most of the systems I check do not use COM objects at all, or just use COM objects to access the database; they still embed scripts in the ASP page to complete business logic. I am not saying that the MVC mode advocates not using scripts on ASP pages. I just said that the script on the ASP page should only be used to support the view and controller functions.

Performance and scalability

When designing a solution based on this mode, you must consider the other two issues. First, how can we improve the performance of this solution? 2. What is the scalability and scalability of this solution? What is it worth scaling up or breaking this model?

Performance

Although accessing the model from the Controller and view is independent of a specific database, it does not mean that the model itself cannot be optimized. Because ADO dataset does not care about the data source, the system performance can be improved without breaking this mode by adopting the database proprietary advantages. For example, compared to using an embedded SQL SELECT statement in your logic function code file (Controller), we can use a stored procedure to return the desired value based on the given parameter. This effect is better. Stored procedures are not only pre-compiled by the database, but also have a pre-determined execution path, so they are executed faster and more efficient.

However, if you use stored procedures to process business logic, you may break this pattern. These business logics should belong to the Controller and allow multiple views to use them. Generally, you can use database-specific features to optimize system performance or force reference integrity, but not to implement controller features.

Scalability and scalability

In order to successfully upgrade, an MVC-mode application has to work in the web server group. As long as you design your application to be stateless or maintain the state between the view and the user (Asp. net by default), you can simply copy your ASPX page and logical function files to multiple IIS servers in a server group, all point to the same database server.

When implementing this mode, I find it useful to separate the logical controller layer into two physical layers. Compared to using the same data access in multiple methods in the Controller layer, I prefer to merge all the code into a single data access object, it is used to access all the data of the application. Microsoft provides a big example, that is, to merge all the data access application modules into a data access layer. You can download this example from msdn. Centralized data access improves code reusability, but more importantly, you can use the actual capacity to set connections to ensure that your applications use the connection pool.

Develop better software at a faster speed

Using design patterns can help you build software that is more reliable and easier to maintain. When designing the system structure for your customers, you should first consider building applications based on the famous design patterns, and then expand these design patterns as needed and performance requirements.