框架模式和设计模式的区别
MVC是一个框架模式,它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件:模型、视图、控制器。它们各自处理自己的任务。最典型的MVC就是JSP + servlet + javabean的模式
我个人的理解就是 框架模式是一座风格独特的房子。而设计模式则是房子里的家具如何摆放的多种选择。
设计模式有 单列模式,工厂模式。
MVC是微软对外公布的第一个开源的表示层框架,MVC目的不是取代WebForm开发,只是web开发的另一种选择。两者最本质区别是请求url不同,MVC是将请求交给控制器处理,而WebForm是将请求交给请求页的后台文件(.cs文件的Page_Load)处理。
MVC优点:
1. 很容易将复杂的应用分成M、V、C三个组件模型,通过model、view、controller有效的简化了复杂的架构,将处理后台逻辑代码与前台展示逻辑进行了很好的分离。
2. 因为没有使用server-based forms,所以程序员控制的会更加灵活,页面更加干净,没有viewstate。
3. 通过修改路由规则,可以控制生成自定义的url,因此控制生成seo友好的url将更加容易。
4. 强类型view实现,更安全,更高效。
WebForm优点:
1. 支持事件模型开发。有丰富的服务器端组件。
2. 控件丰富
WebForm缺点:
1. 封装太强,很多底层东西让初学者不是很明白,
2. 自定义控制不灵活,
3. ViewState处理。
重要参考资料:MVC系列——MVC源码学习:打造自己的MVC框架(一:核心原理)
MVC有路由机制,其实路由机制算是MVC的原理的核心之一
当我们收到一个URL的请求时,服务端收到请求,主要经历以下几个步骤:
1>请求被UrlRoutingModule部件拦截
2>封装请求上下文HttpContext,成为HttpContextWrapper对象。
3>根据当前的HttpContext,从Routes集合中得到与当前请求URL相符合的RouteData对象。
4>将RouteData与HttpContext请求封装成一个RequestContext对象。
5>根据RequestContext对象,从RouteData的RouteHandler中获取IHttpHandler(MVC里面会有一个IHttpHandler的实现类MvcHandler)。
6>执行IHttpHandler(MvcHandler),然后就是通过反射激活具体的controller,执行具体的action。
上图看似复杂,仔细分析就一下几步
1、整个过程有两个核心的组件:UrlRoutingModule和MvcHandler,上文提到的各个过程都和两个组件有紧密的联系。而这两个组件分别继承至IHttpModule和IHttpHandler接口,熟悉Asp.net管线事件的朋友应该会记得这两个接口,在管道事件里面这两个接口扮演着重要角色。要理解MVC的上述原理,必须要先理解这两类接口的原理以及使用。
2、UrlRoutingModule的作用可以理解为通过一系列的与路由相关的组件去解析当前请求的Controller与Action名称,其实简单点理解,比如我们请求http://localhost:8080/Home/Index这个url的时候,UrlRoutingModule拦截到这个请求,然后通过一系列的方式得到这里的“Home”和“Index”,这样理解有没有简单一点呢。
3、MvcHandler的作用就更加直接,上述通过拦截组件得到了请求的Controller和Action的名称,MvcHandler组件将当前请求的Controller名称反射得到对应的控制器对象,然后执行对应的Action方法。比如还是上述http://localhost:8080/Home/Index这个请求,通过字符串“Home”反射成为Home这个类型的控制器对象,然后调用这个对象的Index()方法。
4、综上,联合这两个组件来理解,UrlRoutingMudule组件的主要作用是解析当前的Controller与Action名称,MvcHandler的作用是将得到的Controller名称激活,得到具体的Controller对象,然后执行对应的Action方法。
所以,要理解MVC的原理,必须要了解这两个组件的基本原理以及作用。下面就根据这两个组件分别展开说明,相信理解了下面的内容,你对mvc的原理会有一个新的认识。
我们知道了所有实现了IHttpHandler的类都可以处理Http请求。同样在MVC里面,也定义了一个实现IHttpHandler接口的类型——MvcHandler,用于处理当前的http请求
MvcHandler实现了IHttpHandler、 IHttpAsyncHandler两个接口,它里面有一个
protected virtual void ProcessRequest(HttpContext httpContext)方法,它将HttpContext转换成了HttpContextBase对象,然后又将这个HttpContextBase对象传入protected internal virtual void ProcessRequest(HttpContextBase httpContext)方法中,创建了具体的Controller实例,接着调用这个控制器实例执行了Action方法
namespace System.Web.Mvc
{
public class MvcHandler : IHttpAsyncHandler, IHttpHandler, IRequiresSessionState
{
protected virtual void ProcessRequest(HttpContext httpContext)
{
HttpContextBase httpContext2 = new HttpContextWrapper(httpContext);//将HttpContext转换为HttpContextBase对象将HttpContext转换为HttpContextBase对象
this.ProcessRequest(httpContext2);
}
protected internal virtual void ProcessRequest(HttpContextBase httpContext)
{
IController controller;
IControllerFactory controllerFactory;
this.ProcessRequestInit(httpContext, out controller, out controllerFactory); //通过this.ProcessRequestInit()方法创建具体的Controller实例
try
{
controller.Execute(this.RequestContext); //创建控制器成功之后,在这里就执行Action方法了
}
finally
{
controllerFactory.ReleaseController(controller);
}
}
}
}
除了HttpHandler之外,Asp.net里面还有另外一个重要的角色——HttpModule。和HttpHandler类似,HttpModule指所有实现了IHttpModule接口的一类类型的统称。
通过上文,我们知道HttpHandler的作用非常明确:处理Http请求,生成相应结果。那么,HttpModule又是干什么的呢?
HttpHandler的作用是处理某一类别的请求,比如ashx、aspx、asmx等,在某些情况下,各类请求可能都需要进行某些相同的处理(比如请求拦截、身份认证、检查功能等),不可能在每个类别的HttpHandler里面都去实现这些相同的代码,这个时候怎么办呢?处理某一类通用请求,提高代码的复用率。是不是想到了我们的面向切面编程(AOP),没错,HttpModule就是负责做这个事,HttpModule通过事件订阅的方式,将某类HttpHandler都需要的功能抽取出来,这些功能可以编译成类库供各个模块调用。这种采用事件(观察者)的设计模式使得系统设计上更加灵活。
通过我写的https://blog.csdn.net/Fanbin168/article/details/48847465这篇关于的HttpModule的应用,我们看到在Init方法里面可以拿到当前应用的HttpApplication对象,拿到这个貌似就可以拿到当前请求上下文里面的Request、Response了,是不是就可以处理当前的http请求了,从这点上来说,HttpModule也能处理http请求,或者说具有处理http请求的能力。既然HttpHandler和HttpModule都可以处理http请求,那在使用的时候如何区分呢?上文说过,HttpModule的作用类似AOP,是针对某些通用功能(请求拦截、身份认证、检查功能)的,而HttpHandler常用来处理某一类(ashx、aspx、asmx)http请求,两者的侧重点不同,至于具体在实际中如何使用,你可以自行考量。