Introduction to self-made MVC framework principles

The original use of JSP development program, because a lot of things written in confusion, the project is big or change when it will be very difficult, linkage is too large, sometimes modify the view of things can affect business logic, stratification is not clear.

Later heard of Struts MVC, did a few examples, the level is clear, each actionbean or interceptor have to configure the mapping, configuration to get to the trouble, of course, with the configuration of the way the flexibility of scalability will be much better, but it is too arduous. Then saw spring MVC it can save a lot of configuration, you can use annotations to write directly in the program, the implementation of the 0 configuration.

In the dotnet aspect of the original has not been the concept of MVC, only webform,webform relatively easy to get started, but the more advanced entry feel is not so simple, and webform is not suitable for web app. Later I saw monorail MVC, so after a turn, I decided to make a suitable MVC framework for myself, so I created my own MVC, and I named Stephen.view In fact, the name is STEPHEN.MVC better, but has not changed, it has been to maintain the name. A few years later, Microsoft was also out of MVC, and now there are several versions. Did not study this stuff, the project is still using my self-made this framework. Next, let's talk about my framework implementation principle:

By using the Web. config

<add verb= "*" path= "*.aspx" type= "Stephen.view.templatehandle,stephen.view"/>

...

Block the request with an. aspx extension, and let Stephen.View.TemplateHandle (the class that implements the IHttpHandlerFactory interface) handle the HTTP request, with the following steps:

1. If there is a URL rewrite (which can be written to the configuration in Web. config), then the actual processing URL is executed according to the configuration and skipped if not.

The Web. config is configured as follows:
<configuration>

<configSections>

...

<section name= "Rewriterconfig" type= "Stephen.View.UrlConfig.RewriterConfigSerializerSectionHandler, Stephen.view "/>

...

</configSections>

<RewriterConfig>

<Rules>

<RewriterRule>

<lookfor>~/article/cat/(\d+) .aspx</lookfor>

<sendto>~/integration/info/commonmanagelist_.aspx? Classid=$1</sendto>

</RewriterRule>

</Rules>

</RewriterConfig>

<connectionStrings>

URL rewriting can be consulted: http://www.cnblogs.com/netcorner/archive/2009/12/10/2912045.html

2. Configure which controller to invoke via the real URL address (configurable control component prefix package name via Web. config, default control layer name Netcorner.controllers)

<appSettings>

<add key= "Controller" value= "Netcorner.controllers"/>

</appSettings>

Note: The method of the control layer is not the default session, if you need a session, the control layer method must add the Hassessionattribute feature.

Before the control-layer method is called, a Hashtable object is passed to the control-layer method that holds the current application path (Key=applicationpath), the current path address (currentFilePath), and the View Application processing package (key= Tools, view processing packages can be configured to map which processing package, by default is the Stephen.View.ViewUtility Class)

3. Call the Controller execution method

The controller is actually a simple C # class, such as:

Namespace Netcorner.Controllers.integration

{

public class User

{

Public virtual IDictionary managelist (IDictionary context)

{

...

}

}

}

The Managelist method in the user class is executed when the/integration/user/managelist.aspx is executed, and the context parameter is obtained from Stephen.View.TemplateHandle.

The controller can be written in several ways:

1). Use directly in the method body to write code

2). is the Write plugin (I'm calling C # features plug-ins, which encapsulate some common business, which can be called directly). Each plug-in must implement Beforehandcommonattribute or Proceedplugin abstract classes. The working method can be found in the following chapters.

3). By configuring the dynamic Interceptor. Interceptors must implement Aspectinterceptor abstract classes, which work in the following sections.

4). The Controller method processing is completed to return the corresponding value.

Different types of calls are not the same way

(1). When returning to Hashtable

Invokes a view template. Here I deal with the template engine with nvelocity. Syntax See also: http://www.cnblogs.com/netcorner/archive/2008/07/11/2912125.html

(2). When other types are present, the template is not required as a direct representation of a string.

The access class of the control layer is passed through the URL, the class name executed in the root directory must be default, other words will match the package name and class name to find the appropriate method under the corresponding class. For example:/integration/user/login.aspx It is actually accessing the login method under Netconer.Controllers.integration (I use the default controller) package

Demo Example: Http://files.cnblogs.com/netcorner/%E7%A4%BA%E4%BE%8B1.rar

Next I will talk about the plug-in and interceptor principle and development methods.