Asp. NET MVC design pattern

When developers hear the word "design pattern," they usually associate two scenes. A group of developers are discussing a lot of creative ideas and are having a meeting, but they are not coding. Another group of people can make the right plans to ensure that the system can be developed successfully, the code can be reused.

And reality is generally in the middle of both. When designing solutions for their companies, structural designers and system designers should look for repetitive patterns. But patterns are just a guide to developing robust, reusable code. The structure designer cannot design a solution structure too much, because it has to be delivered on a regular basis.

The main victim of the excessive design system architecture is the Web application. Because most Web applications are used to browse data, the goal is that the data display can keep pace with data updates. In many cases, creating a complex, multi-layered architecture is not intended to meet the needs of users or developers. Let's take a look at a simple example of developing a. NET Web application:

Using ASP.net to realize a classic design pattern

Smalltalk, one of the earliest object-oriented programming languages, provides a platform for developers to quickly develop object-oriented systems. The classic model, View, Controller (MVC) design pattern is developed from this research and is still being used as a reference model. Model saves data that is displayed by view and controlled by controller. View is responsible for sending output to the user, Controller is responsible for responding to the user's actions and updating model accordingly.

Asp. NET provides a good environment for implementing this classic design pattern. Developers implement view by developing user interfaces in ASPX pages. The controller feature is implemented in the logical function code (code-behind) file (Foo.aspx.vb or Foo.aspx.cs).

Implementing this design in. NET provides a two-tier system that has obvious advantages over the classic ASP architecture. Separating the user display (View) from the action (Controller) improves the reusability of the code. Separating the data (Model) from the action (Controller) of its operations allows you to design a system that is not related to storing data 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 SQL Server or in an Oracle database or in a set of XML documents.

Many people will say that developers can easily implement this pattern using ASP pages and COM objects. But the fact is, most of the systems I check don't use COM objects at all, or just use COM objects to access the database; they still embed scripts in the ASP page to complete the business logic. I'm not saying that the MVC pattern advocates not using scripts in ASP pages. I'm just saying that the script in the ASP page should be limited to support view and controller functions.

Performance and Scalability

When designing a solution based on this pattern, you must consider two other issues. First of all, how is the performance of this solution, and how do we improve its performance? Second, what is the scalability and scalability of the solution, and where is it worth expanding or breaking this pattern?

Performance

Although accessing model from controller and view is independent of specific databases, it does not mean that model itself cannot be optimized. Because the ADO dataset does not care about the data source, it can improve system performance by using the advantages of database proprietary without breaking the pattern. For example, rather than using embedded SQL SELECT statements in your logical feature code file (Controller), we can use stored procedures to return the desired values based on the parameters given to them. Stored procedures are not only precompiled in the database, they also have a predetermined execution path, so they execute faster and more efficiently.

However, if you use stored procedures to handle business logic, you may be able to break this pattern. These business logic should belong to the controller, allowing multiple views to use them. You typically use database-specific features to optimize system performance or enforce referential integrity, but not to implement controller features.

Scalability and Scalability

In order to successfully upgrade, an MVC pattern application has to work under a Web server cluster. As long as you design your application to be stateless or maintain a state of view and user (ASP.net defaults to developing this application), you can simply copy your ASPX pages and logical feature files to multiple IIS servers on a server farm, all pointing to the same database server.

When this pattern is implemented, I find it useful to detach the logical controller layer into two physical layers. Rather than replicating in multiple methods in the controller layer using the same data access, I would be more than happy to merge all the code into a single data access object that completes all the data access for the application. Microsoft offers a big example of merging the data Access application modules into a single data access layer, and you can download the example from MSDN. Centralized data access improves code reusability, but more importantly, by using actual capacity to set up connections you can ensure that your application uses connection pooling.

Develop better software at a faster rate

Using design patterns can help you build more reliable and maintainable software. When designing a system structure for your customer, you should first consider building an application based on a well-known design pattern, and then extend the design patterns according to your needs and performance requirements.