Chapter 3 Web representation mode using Micrisoft.net Design Scheme,

Chapter 3 Web representation mode using Micrisoft.net Design Scheme,

Chapter 3 WebExpression mode

The architecture designer is concise and competent in designing the first work. Exercise caution when designing for the first time and clearing what you do. The second work is the most dangerous one. At this time, he will modify and polish the first work, and use the edge design idea of the first design in the second work, results lead to overhead design.

The original Web page was very simple. It only consisted of several simple Html pages to achieve information sharing. As the business develops, it is necessary to decide what to display based on the business. Therefore, CGI programming is developed, a large number of business logic is written into CGI, and then output to the page. With the development, the CGI programming model has been challenged and cannot meet the development needs. As a result, a foliar programming model such as Asp/JSP has been developed, which may embed the business logic into the Html page through scripts, as a result, a large amount of repeated code is flooded in the system, making it difficult to maintain.

There is a conflict between simplicity and complexity when designing a Web system. We strive for simplicity and skill in the design system. However, in order to achieve reuse and with the increase of business complexity, it is inevitable that complicated design methods will be applied. How can we balance the two? There is a way to help us determine whether the complexity of this introduction is to meet the current needs, or to meet future needs? If it is the former, it can increase complexity. This is reasonable. If it is reserved for the future, it is overdesigned. Therefore, you must understand the key Web programming problems, possible solutions, and advantages and disadvantages during design.

Mode Overview

This mode clusters start directly from the long-standing MVC. Since the business logic is separated from the presentation logic, this design mode has been tested for a long time. This mode was first written in the design phase and finally mapped to the Asp. net mvc platform by Microsoft.

 

 

Microsoft®When ASP. NET implements MVC, it starts from a simple system example: it is written on a page and the application logic is embedded into the representation element. As the system becomes more complex, ASP. NET code hiding function is used to separate the representation code (View) from the Model Controller code. This always works well until the requirement forces you to consider reusing model code without a controller to avoid application redundancy. In this case, you need to create an independent model to abstract the business logic and use the code hiding function to adapt the model to the view code. Then, the implementation process ends the discussion of the meaning of the MVC method test.

So far, models and views have been emphasized when Model-View-Controller mode is used; controllers play relatively secondary roles. Actually, the Controller that works in this mode is an implicit controller in ASP. NET. It is responsible for perceiving user events (requests and replies) and writing these events into appropriate system responses.

In a Web-based dynamic application, many common tasks are repeated each time a page request is made, such as user verification, confirmation, extraction of request parameters, and searching for databases related to the representation. If you do not manage these tasks, unnecessary code duplication will soon occur. Because these tasks are completely related to user event awareness and determining the correct system response, the logical location used to place the behavior is in the controller.

More powerful control

The next mode in this cluster is Page Controller, which is an optimization of Model-View-Controller and can meet the complexity of the next level. This mode uses a controller in the page range to accept the input from the page request, call the request operation for the model, and then determine the correct view to use as the result page. Repeated logic (such as validation) is moved to the basic controller class.

Using ASP. NET to implement Page Controller describes the powerful functions of the built-in Page Controller of ASP. NET with common appearance examples. The implementation process also uses the Template Method mode and Page Controller mode to define the algorithm framework in the operation, and submits some of the steps to the subclass for responsibility.

As applications become more and more complex, the page controller accumulates a large number of logics in the base class. This problem is usually solved by deepening the inheritance hierarchy of the page controller. If the application is very complex, both of these factors will make the code difficult to maintain and expand. Similarly, some applications need to dynamically configure the navigation chart, which may span multiple page controllers. To achieve this complexity, consider the Front Controller ).

The Front Controller is the next mode in the directory. It is also optimized for Model-View-Controller. In the front-end controller, all requests are sent through a single (usually two parts) controller. The first component of the controller is the processing program, and the second component is the Commands hierarchy. The command itself is a part of the controller, representing a specific operation triggered by the Controller. After executing this operation, select the view to use to display the page. Generally, the constructed controller framework maps requests to operations using the configuration file, so it is easy to change after building. Of course, its disadvantage lies in the inherent complexity of this design.

Filter and Cache

The last two modes in this cluster involve filters and caches.

I ntercepting Filter provides a solution to the following problems: how to implement common preprocessing and post-processing for HTTP requests. In Intercepting Filter, it is most suitable for executing non-application-specific common tasks, such as security checks, logging, compression, encoding, and decoding. Intercepting Filter usually involves executing a specific task. When multiple tasks are executed for an HTTP request, multiple filters are linked together. Using the HTTP module in ASP. NET to implement Intercepting Filter emphasizes that this mode can be conveniently implemented in ASP. NET.

Page Cache satisfies the increasing scalability and performance requirements of Web applications by retaining copies of frequently-used dynamic Web pages that are frequently created at an extremely high cost. After the page is initially created, a copy is sent to respond to future requests. Page Cache also discusses several key Cache design factors, such as Cache refresh, data refresh, and Cache granularity. Using absolute expiration in ASP. NET to implement Page Cache describes the built-in Page Cache function of ASP. NET.

PageController (Page Controller)

Context

You have decided to use the Model-View-Controller (MVC) mode to separate the user interface components of Dynamic Web applications from the business logic. The application to be built will construct the webpage dynamically, but the navigation between webpages is mostly static navigation.

Problem

How can we build controllers for moderately complex Web applications in the best way to avoid code duplication and achieve reusability and flexibility?

Influencing Factors

The following factors affect the system in this situation and must be coordinated when considering the above problem solution:

The MVC mode usually focuses on the separation between models and views, but less on controllers. In many fat client solutions, the separation between controllers and views is relatively secondary, so [Fowler03] is usually ignored. However, in a thin client application, the view and controller are separated, because the display is performed in the client browser, and the controller is a part of the server application. Therefore, it is necessary to study the Controller more carefully.

In a dynamic Web application, multi-user operations can lead to different controller logics, and the same page is displayed. For example, in a Web-based simple email application, both sending and deleting emails from the inbox may return the user to the inbox page (refreshed. Although the two activities show the same page after completion, the application must perform different operations based on the previous page and the button clicked by the user.

The code for displaying most dynamic web pages involves very similar steps: authenticate the user identity, extract page parameters from the query string or form field, collect session information, retrieve data from the data source, generate dynamic pages, and add applicable headers and footers. This may cause a large number of code duplicates.

Script-based Server Pages (such as ASP. NET) can be easily created, but may cause some disadvantages when applications increase. Scripting pages cannot better separate controllers and views, thus reducing the possibility of reuse. For example, if multiple operations lead to the same page, it is difficult to reuse the display code between multiple controllers because the display code is mixed with the Controller code. It is more difficult to test and debug the script-based Server Pages distributed between the business logic and the display logic. Finally, developing a script-based server page requires both proficient in developing business logic and creating beautiful and efficient HTML pages. Few of them have both of these skills. Based on the above considerations, it is necessary to minimize the Page code of the script-based server and develop the business logic in the actual class.

As described in the MVC mode, user interface code testing is often time-consuming and monotonous. If the user interface dedicated code and actual business logic can be separated, testing business logic is simpler and more reproducible. This is true for both the display part and the application controller part.

The general appearance and navigation structure can often improve the availability and brand awareness of Web applications. However, the general appearance may result in duplicate display code, especially when the code is embedded in the script server page. Therefore, a mechanism is required to improve the reusability of the display logic between pages.

Solution

Use the Page Controller mode to accept the input from the Page request, call the request to perform operations on the model, and determine the correct view applied to the result Page. Separate the scheduling logic and all view-related code. If appropriate, create a public base class for all page controllers to avoid code duplication and improve consistency and testability. Figure 1 shows the relationship between the page controller and the model and view.

 

The page controller can receive page requests, extract all relevant data, call all updates to the model, and forward requests to the view. The view retrieves the data to be displayed based on the model. The define independent page controller separates model and Web request details (for example, session management, or passing parameters to the page using query strings or hiding form fields ). Create a controller for each link in the Web application in this basic form. The Controller becomes very simple because only one operation is required at a time.

Creating an independent controller for each webpage (or operation) may result in a large number of code duplicates. Therefore, you should create a BaseController class to merge common functions such as verification parameters (see figure 2. Each Independent page controller can inherit this public function from BaseController. In addition to inheriting from the public base class, a set of helper classes can also be defined. controllers can call these classes to execute public functions.

 

This method is very effective if most pages are similar and public functions can be put into a base class. The more page changes, the more levels that must be inserted into the inheritance tree. For example, parameters are analyzed on all pages, but data is retrieved from the database only on the page that displays the list. On the page that requires data input, the model is updated without data retrieval. Now we can introduce two new base classes, ListController and DataEntryController. Both of these classes inherit the BaseController. The list page can be inherited from ListController, while the data input page can be inherited from DataEntryController. Although this method is very effective in this simple example, the inheritance tree may be very deep and complex when dealing with actual business applications. You may want to add the condition logic to the base class to adapt to certain variants. However, this operation violates the encapsulation principle, and the base class may cause a lot of trouble when changing the system. Therefore, when applications become more complex, you should consider using the helper class or Front Controller mode.

Most Web application frameworks use page controllers by default. Most frameworks include page controllers (such as ASP, JSP, and PHP) in the form of server pages ). The server page actually combines the view and controller functions, but does not provide corresponding separation between the display code and the Controller code. Unfortunately, for some frameworks, mixed view-related code and controller-related code are easy, but it is difficult to correctly separate the Controller logic. Therefore, the Page Controller method has poor reputation among many developers. Nowadays, many developers associate Page Controller with poor design, while Front Controller with better design. In fact, this feeling is caused by imperfect implementation. Both Page Controller and Front Controller are highly feasible architectures.

Therefore, it is best to put the Controller logic separately into an independent class that can be called from the server page. The ASP. NET page framework provides a complete mechanism to implement such separation. This mechanism is called "code hiding class ".

Variant

In most cases, the page controller depends on the details of HTTP-based Web requests. Therefore, the page controller Code usually contains references to HTTP headers, query strings, form fields, and multiple form requests. Therefore, it is very difficult to test the Controller code outside the Web application framework. The only method is to test the controller by simulating HTTP requests and analysis results. This type of test is time-consuming and error-prone. Therefore, to improve testability, you can put the code that depends on the Web and the code that does not depend on the Web into two separate classes (see figure 3 ).

 

In this example, AspNetController encapsulates all dependencies on the application framework (ASP. NET. For example, it can extract all input parameters from Web requests and pass them to BaseController in a way independent of the Web interface (for example, using a set. This method not only improves testability, but also allows reuse of the controller code through other user interfaces, such as the fat client interface or custom scripting language.

The disadvantage of this method is that it increases the overhead. Now a new class is added, and it must be converted before processing each request. Therefore, we should try our best to control the environmental impact, and weigh the options to reduce dependencies and improve development efficiency and execution efficiency.

Result Context

Using the Page Controller mode has the following advantages and disadvantages.

Advantages

Simplicity. Since each dynamic web page is processed by a specific controller, these controllers only need to process a limited range to maintain simplicity. Since each Page Controller only processes one Page, Page Controller is especially suitable for Web applications with simple navigation structure.

Built-in framework functions. In most basic forms, controllers have been placed on most Web application platforms. For example, if you click a link to a dynamic page generated by an ASP. NET script, the Web server analyzes the URL associated with the link and executes the relevant ASP. NET page. In fact, these ASP. NET pages are the controllers of operations performed by users. The ASP. NET page framework also provides a code hiding class for executing controller code. The Code hiding class provides better separation between controllers and views, and allows you to create a function controller base class that combines all controllers. For examples, see "Implementing Page Controller in ASP. NET ".

Enhanced reusability. Creating a controller base class can reduce code duplication and allow the Controller to reuse public code on different pages. Code can be reused by implementing repeated logic in the base class. Then, all specific Page Controller objects will automatically inherit this logic. If the implementation of this logic varies with different pages, you can still use the Template Method in the base class and implement the basic execution structure; the implementation of specific sub-steps may vary depending on the page.

Scalability. By using the helper class, you can easily extend the page controller. If the logic in the controller is too complex, you can delegate some logic to the helper class. In addition to inheritance, helper classes also provide a reuse mechanism.

The separation of developers' responsibilities. Using the Page Controller class helps to separate the responsibilities of members in the development team. Controller developers must be familiar with the domain model and business logic implemented by applications. On the other hand, view designers can focus on the display style of results.

Disadvantages

Due to its simplicity, Page Controller is the default Implementation Method for most dynamic Web applications. However, you should understand the following restrictions:

Each page has one controller. The main disadvantage of Page Controller is to create a Controller for each webpage. This feature is very suitable for applications with a set of static pages and simple navigation paths. Some complex applications require dynamic ing of navigation ing between pages. If this logic is distributed across many page controllers, it may make it difficult for applications to maintain, even if some logics can be placed in the basic controller. In addition, the built-in functions of the Web framework may reduce the flexibility of naming URLs and resource paths (although you can use lower-level mechanisms such as ISAPI filters to make some compensation ). In these scenarios, consider using the Front Controller to intercept all Web requests and forward these requests to the corresponding handler according to configurable rules.

Deep inheritance tree. Inheritance seems to be one of the most cute and annoying functions based on object programming. If you only use inheritance to reuse public functions, the flexibility of the inheritance hierarchy may be reduced. For more information, see "Implementing Page Controller in ASP. NET ".

The dependency on the Web framework. In the basic form, the page controller still depends on the Web application environment and cannot be tested separately. You can use a packaging machine to separate Web-dependent parts, but this requires an additional level of indirect.

Test considerations

Because Page Controller depends on the details of the Web application framework (for example, query strings and HTTP headers), you cannot instantiate or test the Controller class outside the Web framework. If you want to run a set of automatic unit tests on the Controller class, you must start the Web application each time you test. Then, you must submit an HTTP request in the format that can execute the required functions. This configuration has many dependencies and adverse effects on testing. To improve testability, consider separating business logic (including more complex controller logic) from Web-dependent code.