ASP.NET MVC的流程讲解

开始想这个标题的时候，很是忧郁到底叫什么标题会比较好哪，最后还是确定为讲解，虽然略显初级，但是很多概念，想通了还是比较有价值的。废话略过，开始！

1、MVC的基本开发流程

 

2、webform和MVC的选择

 

3、MVC的内部过程

1、MVC的开发流程

MVC的出现时微软在2009年左右开始提出的网站开发的新的发展方向，这个方面的开发官方解释是可以比较好的实现三层分离，而且分离之后，可以实现复用等相关好处，通常人们列举的例子是ui方面可以同时支持HTML网络或者WAP网络。但是其实个人的理解是，动态网站的开发经过不断地证实和发展，java的struts模型，可以提高开发速度，也可以降低差多，是比较好的框架，而微软也需要提供自己的开发框架。不能够只是一个界面一个界面的设计方式，设计模式逐步进入到了web开发的领域。

MVC使用vs2010进行开发时（这里介绍的是MVC2），首先需要选在一个模板，然后vs2010会帮忙创建好对应的目录结构。

每个目录的基本功能：

Content：主要用于描述css之类的资源

Controllers：主要就是controller的存放位置，创建controller时，都是需要在该目录创建的。

Models：主要就是entity的具体位置，以及跟entity相关的操作类

Scripts：javascript脚本存放的位置

Views：该部分主要是放置view显示部分的

Global.asax：目前来看，该部分主要就是路由设置

Web.config：该配置文件而已

从开发的流程方面来看，MVC的开发方式，或者说思考的方式出现了变化，在MVC当中，需要理解一个重要的点是：

Controller才是系统的中心，一切围绕Controller展开。

Model：所谓模型，可以理解为数据，这个数据可以是数据库中对应的表中的数据，这种数据是只有属性，而没有动作的，这种数据通常也被称之为Entity，即实体，除了这种数据之外，MODLE起始还要包括Interface，这些接口的目标是提供可以控制Entity的接口标准，然后在提供实现的载体，通常我们称之为Mock类，为了方便，可能我们还会在Model当中创建各种factory，从而简化对象的创建。

Controller：这个部分就是核心了，其实所谓核心，是说所有的处理，全部围绕着Controller展开，它的主要工作是访问model，获取数据后，将参数转发给view，然后让view表现出来。在这里主要完成的工作有两点：

1、在客户端访问一个页面后，需要跳转到Controller对应的action中去，然后在action中处理对应的view显示出来。

2、 完成客户的表单提交相应处理，也就是Form表单处理。(还记得之前讲过，对于HTML而言，只有Form表单实现了客户端的信息发送给服务端，然后由服务端处理相关的相应，因为MVC的设计目标就是放弃了微软原有的服务器控件，因此一切回归原始，采用HTML的form表单方式实现提交和相关的控制处理。)

View：顾名思义，该部分就是现实的部分，这个部分需要时刻记住的是，这个view虽然也是aspx的页面，但是已经发生了根本性的变化，不再有所谓的codebeind代码了，这个view的所有变成将采用混合式的变成，你会注意到这个部分的变成变为HTML与C#的混合，会出现很多的<%%><%=%>类似的代码。很多人起始对这个部分有不同的开发，混合代码对于分层不利，但是在MVC中，因为不涉及逻辑，所以view的表现变得简单，混合编程会变为可以接受的处理方式。另外，这种方式带来的好处是，美工可以介入了，他们的修改对于程序员来说，没有什么特别，也是非常容易直接引入的。带来的坏处是Gridview这种强大的服务器控件被丢弃了。虽然是这样，但是我个人觉得，这是回到了web开发的本质。他的思想，与JSP,PHP等等变为一致。

Golabal.asax：路由表，这个部分就是所谓的全局路由表。在MVC框架中，之所以实现了MVC功能，一个重要的概念是路由表，该部分实现了地址访问的动态，不再提供具体页面的访问模式。

注意：给我的感觉是，记住在view目录和model目录中，添加子目录，每个controller对应的view，都是一个目录下的view。这个是MVC框架查找时自动搜索的。

2、webform和MVC的选择

这个部分的争论，我想从微软开始推出MVC框架后，大家就在不间断的讨论着，不同的人，给出的看法也是不同，就我个人而言，我觉得MVC才是未来趋势，是世界最后大同的根本。尽管web form的模式，是微软开创性的创造，但是毕竟web开发不是微软首创，很多时候，大势所趋而已。我这里只是想谈谈两者的思想出发点的差别：

  • webform模式，这个模式的思维基础，是微软在桌面开发中取得了前所未有的成功，这些成功，微软希望复制到网络开发中，何为form，就是窗口开发，这种框架的逻辑是所见即所得+事件处理，微软希望可以将web实现为桌面开发的模式，但是网络开发的基础是HTML和HTTP协议，这两个部分带来的问题是HTML表现元素有限，并且只能够通过form与后台服务器通信。另外，HTTP协议无状态，无法实现消息机制，为了解决这些问题，微软创造了新的开发模式，引入ASP.NET服务器控件，实现了丰富的控件，通过postback回传机制，实现了事件模型，通过codebehind技术实现web页面与C#代码的分离。上述技术，的确非常成功，也确实很大程度上简化了web的开发，但是随着发展，带来了问题，就是webform的开发基础是页面化的，这种思维模式是说你开一个页面，然后在这个页面写响应事件，但是这种模式对于频繁变化的web程序缺乏良好的复用性，并且，前端人员开发的界面，往往在合成时，需要重做，这是微软自己创造的困难，这是一种以Page为中心的开发思想。
  • MVC模式，这个模式的思维基础，是分工清晰，以Controller为核心，在开发时可以先做model再做Controller，最后做view，通过使用demo view实现，最后再替换美工的view。这种模式变成了以数据为中心的开发思想。最大的好处是，这种模式中每个部分都可以灵活复用，最大限度的实现现在的各种网络需要，比如互联网和移动互联网。而且，其他的变成语言，在思想方面也基本采用这种模式，这种模式最终被时间证明，成为了标准思考方式和开发方式。微软提倡的桌面化开发，渐渐退却往日之光芒。

3、MVC的内部过程

这个部分是个非常核心的问题，本文除了自己理解，还大量引用了其他相关的文章。尝试讲解清楚MVC的基本运转流程。

MVC的主体过程：

问题：

1、 浏览器请求的地址，并不是具体的某个页面，如1234.aspx页面，而是controller/action方法，这是如何做到的？

2、 Controller被访问到以后，如何找到具体的view进行返回的？

我个人的理解就是回答了上述的问题，也就解释清楚了MVC的基本框架。

第一个问题，浏览器请求地址的问题，MVC之所以能够找到具体的Controller是因为有一个route组件，实现了路由处理的功能，将请求转化为Controller的具体方法。需要注意该组件居然是个独立组件。

Routing的作用：

1、 解析URL，识别当中的参数

2、 解析之后，调用具体的controller和action

比如首页地址是: localhost/home/index

我们发现访问上面的地址,
最后会传递给 HomeController中名为index的action(即HomeController类中的index方法).

当然服务器端不会自己去实现这个功能, 
关键点就是在Global.asax.cs文件中的下列代码:

        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
 
            routes.MapRoute(
                "Default",                                              // Route name
                "{controller}/{action}/{id}",                           // URL with parameters
                new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
            );
 
        }
 
        protected void Application_Start()
        {
            RegisterRoutes(RouteTable.Routes);
        }

回来看我们的Url: localhost/home/index

localhost是域名,
所以首先要去掉域名部分: home/index

对应了上面代码中的这种URL结构:{controller}/{action}/{id}

因为我们建立了这种Url结构的识别规则,
所以能够识别出 Controller是home,action是index,id没有则为默认值"".

上述功能之所以能够实现，关键在MapRoute方法，虽然MapRoute方法是RouteCollection对象的方法,但是却被放置在System.Web.Mvc程序集中,
如果你的程序只引用了System.Web.Routing,
那么RouteCollection对象是不会有MapRoute方法的.
但是如果你同又引用了System.Web.Mvc,
则在mvc的dll中为RouteCollection对象添加了扩展方法:

       public static void IgnoreRoute(this RouteCollection routes, string url);
        public static void IgnoreRoute(this RouteCollection routes, string url, object constraints);
        public static Route MapRoute(this RouteCollection routes, string name, string url);
        public static Route MapRoute(this RouteCollection routes, string name, string url, object defaults);
        public static Route MapRoute(this RouteCollection routes, string name, string url, string[] namespaces);
        public static Route MapRoute(this RouteCollection routes, string name, string url, object defaults, object constraints);
        public static Route MapRoute(this RouteCollection routes, string name, string url, object defaults, string[] namespaces);
        public static Route MapRoute(this RouteCollection routes, string name, string url, object defaults, object constraints, string[] namespaces);

RouteCollection是一个集合,他的每一项应该是一个Route对象.
但是我们使用MapRoute时并没有创建这个对象,
这是因为当我们将MapRoute方法需要的参数传入时,
在方法内部会根据参数创建一个Route对象:

        public static Route MapRoute(this RouteCollection routes, string name, string url, object defaults, object constraints, string[] namespaces) {
            if (routes == null) {
                throw new ArgumentNullException("routes");
            }
            if (url == null) {
                throw new ArgumentNullException("url");
            }
 
            Route route = new Route(url, new MvcRouteHandler()) {
                Defaults = new RouteValueDictionary(defaults),
                Constraints = new RouteValueDictionary(constraints)
            };
 
            if ((namespaces != null) && (namespaces.Length > 0)) {
                route.DataTokens = new RouteValueDictionary();
                route.DataTokens["Namespaces"] = namespaces;
            }
 
            routes.Add(name, route);
 
            return route;
        }

上面就是MapRoute方法的实现,
至于在创建Route对象时第二个参数是一个MvcRouteHandler,
它是一个实现了IRouteHandler接口的类. IRouteHandler十分简单只有一个方法:

IHttpHandler GetHttpHandler(RequestContext requestContext);

参数是一个RequestContext
类实例,
这个类的结构也很简单:

    public class RequestContext
    {
        public RequestContext(HttpContextBase httpContext, RouteData routeData);
 
        public HttpContextBase HttpContext { get; }
        public RouteData RouteData { get; }
    }

其中的一个属性RouteData就包含了Routing根据Url识别出来各种参数的值,
其中就有Controller和Action的值.

归根结底, ASP.NET MVC最后还是使用HttpHandler处理请求. ASP.NET MVC定义了自己的实现了IHttpHandler接口的Handler:MvcHandler, 
因为MvcRouteHandler的GetHttpHandler方法最后返回的就是MvcHandler.

MvcHandler的构造函数需要传入RequestContext
对象,
也就是传入了所有的所有需要的数据,
所以最后可以找到对应的Controller和Action,
已经各种参数.

（引用参考：http://www.cnblogs.com/zhangziqiu/archive/2009/02/28/ASPNET-MVC-2.html）

（引用参考：http://www.cnblogs.com/zhangziqiu/archive/2009/03/11/Aspnet-MVC-3.html）

第二个问题：Controller找到了，Action也找到了，此时如何哪？

下面分层次的总结Controller处理流程:

1. 页面处理流程

发送请求 –> UrlRoutingModule捕获请求 –>MvcRouteHandler.GetHttpHandler() –> MvcHandler.ProcessRequest()

2.MvcHandler.ProcessRequest() 处理流程:

使用工厂方法获取具体的Controller –> Controller.Execute() –>
释放Controller对象

3.Controller.Execute() 处理流程

获取Action –>
调用Action方法获取返回的ActionResult –>
调用ActionResult.ExecuteResult() 方法

4.ActionResult.ExecuteResult() 处理流程

获取IView对象->
根据IView对象中的页面路径获取Page类->
调用IView.RenderView() 方法(内部调用Page.RenderView方法)

通过对MVC源代码的分析,我们了解到Controller对象的职责是传递数据,获取View对象(实现了IView接口的类),通知View对象显示.View对象的作用是显示.虽然显示的方法RenderView()是由Controller调用的,但是Controller仅仅是一个"指挥官"的作用,
具体的显示逻辑仍然在View对象中.需要注意IView接口与具体的ViewPage之间的联系.在Controller和View之间还存在着IView对象.对于ASP.NET程序提供了WebFormView对象实现了IView接口.WebFormView负责根据虚拟目录获取具体的Page类,然后调用Page.RenderView().

引用参考：（Http://www.cnblogs.com/zhangziqiu/archive/2009/03/11/Aspnet-MVC-3.html）

讲到这里，相信很多人开始似乎明白了，又似乎不明白了，下面我做进一步的讲解，先看一下，通常Controller的实现如下：

    public class HomeController:Controller
    {
        public ActionResult Index()
      {
            Return View(“Index”);
}
    }

先看看关键类ActionResult，这个返回值，体现了微软精心设计，为什么做这么个类，其实本质而言，微软希望这个action可以返回更多内容，而不仅仅是view。


类名
抽象类
父类
功能

ContentResult
根据内容的类型和编码,数据内容.

EmptyResult
空方法.

FileResult
abstract
写入文件内容,具体的写入方式在派生类中.

FileContentResult
FileResult
通过文件byte[]
写入文件.

FilePathResult
FileResult
通过文件路径写入文件.

FileStreamResult
FileResult
通过文件Stream
写入文件.

HttpUnauthorizedResult
抛出401错误

JavaScriptResult
返回javascript文件

JsonResult
返回Json格式的数据

RedirectResult
使用Response.Redirect重定向页面

RedirectToRouteResult
根据Route规则重定向页面

ViewResultBase
abstract
调用IView.Render()

PartialViewResult
ViewResultBase
调用父类ViewResultBase
的ExecuteResult方法.

重写了父类的FindView方法.

寻找用户控件.ascx文件

ViewResult
ViewResultBase
调用父类ViewResultBase
的ExecuteResult方法.

重写了父类的FindView方法.

寻找页面.aspx文件

这里我们主要讲解viewResult的作用。

在ASP.NETMVC中，ViewResult用的最多，Controller有一个View方法，它来实例化一个ViewResult对象，并返回。

下面是View方法：

protected internal virtual ViewResult View(string viewName, string masterName, object model) {
    if (model != null) {
        ViewData.Model = model;
    }

    return new ViewResult {
        ViewName = viewName,
        MasterName = masterName,
        ViewData = ViewData,
        TempData = TempData
    };
}

ViewResult类的ExecuteResult方法的具体参考如下：

public override void ExecuteResult(ControllerContext context) {
    if (context == null) {
        throw new ArgumentNullException("context");
    }
    if (String.IsNullOrEmpty(ViewName)) {
        ViewName = context.RouteData.GetRequiredString("action");
    }
    ViewEngineResult result = null;
    if (View == null) {
        result = FindView(context);  // 很关键，找到具体的view
        View = result.View;
    }
    ViewContext viewContext = new ViewContext(context, View, ViewData, TempData);
// 很关键，渲染自己
    View.Render(viewContext, context.HttpContext.Response.Output);
    if (result != null) {
        result.ViewEngine.ReleaseView(context, View);
    }
}

那么如何FindView哪？具体如下：

rotectedoverrideViewEngineResult FindView(ControllerContext context) {

ViewEngineResult result =ViewEngineCollection.FindView(context, ViewName, MasterName);

if (result.View !=
null) {

return result;

}

//we need to generate an exception containing all the locations we searched

StringBuilder locationsText =
new StringBuilder();

foreach (string location
in result.SearchedLocations) {

locationsText.AppendLine();

locationsText.Append(location);

}

throw
new InvalidOperationException(String.Format(CultureInfo.CurrentUICulture,

MvcResources.Common_ViewNotFound,ViewName, locationsText));

}

从ViewResult类的FindView方法中，得知ViewEngineResult是通过ViewEngineCollection的FindView得到的，而ViewEngineCollection正是ViewEngines的静态属性Engines,Engines返回一个只有一个WebFormViewEngine类型实例的一个集合。所以，ViewEngineResult会是调用WebFormViewEngine类的FindView方法返回的结果。如果ViewEngins的静态属性Engines有多个ViewEngine提供，那么就依次遍历它们直到找到第一个不为空的ViewEngineResult为止。这样我们就可以在同一个MVC网站中使用多种视图引擎了。

静态类ViewEngines的描述如下：

public static class ViewEngines
 {
  private static readonly ViewEngineCollection _engines = new ViewEngineCollection { new WebFormViewEngine(), new RazorViewEngine() };
   
      public static ViewEngineCollection Engines
    {
        get { return _engines;}
     }
 }
  
  public class ViewEngineCollection : Collection<IViewEngine>
 {
     //其他成员
 public virtual ViewEngineResult FindPartialView(ControllerContext controllerContext, string partialViewName);
 public virtual ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName);
 }

从上述例子可以看出，起始微软为我们提供了两个ViewEngine, WebFormViewEngine和RazorViewEngine，WebFormViewEngine对应的是ASPX界面，RazorViewEngine对应的是.cshtml/.vbhtml引擎

此外，这里有一个隐藏很深的概念，似乎很多书都没讲清楚，每一个引擎都会对应一个view，作为页面渲染使用，对于viewengine做进一步的解释，就是说，为什么一个view当中的<%%>之类的界面元素最后可以变成html，就是这些引擎在起作用，他们的内部实现，可以提供类似正则表达式或者是页面parsing的方法，完成页面字符串解析，从而转换为对应的html，再response给客户端浏览器。

微软提供的两种viewengine和view如下：

RazorViewEngine和Razorview

（参考引用：http://www.cnblogs.com/artech/archive/2012/09/05/razor-view-engine-02.html）

WebformViewengine和Webformview

通过上边的讲述，基本的概念已经讲清楚了，如果希望实现自己的viewengine，可以查看一下微软参考实现是如何做到的，然后我们就可以防治自己的viewengine了。这里便需要进一步说明的是，为什么MVC需要viewengine，而WEBFORM不需要，是因为，微软的webform是直接通过IHttphandler处理了，也就是说ASP.NETWEBFORM模式中的HTTPHANDLER完成了事件处理和页面显示的双重功能。而ASP.NETMVC没有事件处理，因此页面显示被划到了viewengine当中实现了。事件处理，被controller替换处理了。

微软的Razorview和Webformview本质上是实现于IView接口，而WebformViewengine和Webformview本质上是实现于IViewEngine

下面介绍他们的实现逻辑：

public interface IView
   2: {    
   3:     void Render(ViewContext viewContext, TextWriter writer);
   4: }
   5:  
   6: public class ViewContext : ControllerContext
   7: {
   8:     //其他成员
   9:     public virtual bool ClientValidationEnabled { get; set; }
  10:     public virtual bool UnobtrusiveJavaScriptEnabled { get; set; }
  11:  
  12:     public virtual TempDataDictionary TempData { get; set; }    
  13:     [Dynamic]
  14:     public object                     ViewBag { [return: Dynamic] get; }
  15:     public virtual ViewDataDictionary ViewData { get; set; }
  16:     public virtual IView              View { get; set; }
  17:     public virtual TextWriter         Writer { get; set; }
  18: }
  19:  
  20: public abstract class HttpResponseBase
  21: {
  22:     //其他成员
  23:     public virtual TextWriter Output { get; set; }
  24: }
 
 
1: public interface IViewEngine
   2: {    
   3:     ViewEngineResult FindPartialView(ControllerContext controllerContext, string partialViewName, bool useCache);
   4:     ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache);
   5:     void ReleaseView(ControllerContext controllerContext, IView view);
   6: }
1: public class ViewEngineResult
   2: {    
   3:     public ViewEngineResult(IEnumerable<string> searchedLocations);
   4:     public ViewEngineResult(IView view, IViewEngine viewEngine);
   5:    
   6:     public IEnumerable<string> SearchedLocations { get; }
   7:     public IView               View { get; }
   8:     public IViewEngine         ViewEngine { get; }
   9: }
1: public class ViewResult : ViewResultBase
   2: {    
   3:     protected override ViewEngineResult FindView(ControllerContext context);
   4:     public string MasterName { get; set; }
   5: }
   6:  
   7: public abstract class ViewResultBase : ActionResult
   8: {   
   9:     public override void ExecuteResult(ControllerContext context);
  10:     protected abstract ViewEngineResult FindView(ControllerContext context);
  11:   
  12:     public object                     Model { get; }
  13:     public TempDataDictionary         TempData { get; set; }    
  14:     [Dynamic]
  15:     public object                     ViewBag { [return: Dynamic] get; }
  16:     public ViewDataDictionary         ViewData { get; set; }   
  17:     public string                     ViewName { get; set; }
  18:     public ViewEngineCollection       ViewEngineCollection { get; set; }
  19:     public IView                      View { get; set; }
  20: }

（参考引用：http://www.cnblogs.com/artech/archive/2012/08/22/view-engine-01.html）

自定义的View以及相关的Viewengine,参考如下：

public class StaticFileView:IView
   2: {
   3:     public string FileName { get; private set; }
   4:     public StaticFileView(string fileName)
   5:     {
   6:         this.FileName = fileName;
   7:     }
   8:     public void Render(ViewContext viewContext, TextWriter writer)
   9:     {
  10:         byte[] buffer;
  11:         using (FileStream fs = new FileStream(this.FileName, FileMode.Open))
  12:         { 
  13:             buffer = new byte[fs.Length];
  14:             fs.Read(buffer, 0, buffer.Length);
  15:         }
  16:         writer.Write(Encoding.UTF8.GetString(buffer));
  17:     }
  18: }
internal class ViewEngineResultCacheKey
   2: {
   3:     public string ControllerName { get; private set; }
   4:     public string ViewName { get; private set; }
   5:  
   6:     public ViewEngineResultCacheKey(string controllerName, string viewName)
   7:     {
   8:         this.ControllerName = controllerName ?? string.Empty;
   9:         this.ViewName = viewName ?? string.Empty;
  10:     }
  11:     public override int GetHashCode()
  12:     {
  13:         return this.ControllerName.ToLower().GetHashCode() ^ this.ViewName.ToLower().GetHashCode();
  14:     }
  15:  
  16:     public override bool Equals(object obj)
  17:     {
  18:         ViewEngineResultCacheKey key = obj as ViewEngineResultCacheKey;
  19:         if (null == key)
  20:         {
  21:             return false;
  22:         }
  23:         return key.GetHashCode() == this.GetHashCode();
  24:     }
  25: }
1: public class StaticFileViewEngine : IViewEngine
   2: {
   3:     private Dictionary<ViewEngineResultCacheKey, ViewEngineResult> viewEngineResults = new Dictionary<ViewEngineResultCacheKey, ViewEngineResult>();
   4:     private object syncHelper = new object();
   5:     public ViewEngineResult FindPartialView(ControllerContext controllerContext, string partialViewName, bool useCache)
   6:     {
   7:         return this.FindView(controllerContext, partialViewName, null, useCache);
   8:     }
   9:  
  10:     public ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
  11:     {
  12:         string controllerName = controllerContext.RouteData.GetRequiredString("controller");
  13:         ViewEngineResultCacheKey key = new ViewEngineResultCacheKey(controllerName, viewName);
  14:         ViewEngineResult result;
  15:         if (!useCache)
  16:         { 
  17:             result = InternalFindView(controllerContext, viewName, controllerName);
  18:             viewEngineResults[key] = result;
  19:             return result;
  20:         }
  21:         if(viewEngineResults.TryGetValue(key, out result))
  22:         {
  23:             return result;
  24:         }
  25:         lock (syncHelper)
  26:         {
  27:             if (viewEngineResults.TryGetValue(key, out result))
  28:             {
  29:                 return result;
  30:             }
  31:  
  32:             result = InternalFindView(controllerContext, viewName, controllerName);
  33:             viewEngineResults[key] = result;
  34:             return result;
  35:         }             
  36:     }
  37:  
  38:     private ViewEngineResult InternalFindView(ControllerContext controllerContext, string viewName, string controllerName)
  39:     {
  40:         string[] searchLocations = new string[]
  41:         {
  42:             string.Format( "~/views/{0}/{1}.shtml", controllerName, viewName),
  43:             string.Format( "~/views/Shared/{0}.shtml", viewName)
  44:         };
  45:  
  46:         string fileName = controllerContext.HttpContext.Request.MapPath(searchLocations[0]);
  47:         if (File.Exists(fileName))
  48:         {
  49:             return new ViewEngineResult(new StaticFileView(fileName), this);
  50:         }
  51:         fileName = string.Format(@"\views\Shared\{0}.shtml", viewName);
  52:         if (File.Exists(fileName))
  53:         {
  54:             return new ViewEngineResult(new StaticFileView(fileName), this);
  55:         }
  56:         return new ViewEngineResult(searchLocations);
  57:     }
  58:  
  59:     public void ReleaseView(ControllerContext controllerContext, IView view)
  60:     { }
  61: }
1: public class MvcApplication : System.Web.HttpApplication
   2: {
   3:     protected void Application_Start()
   4:     {
   5:         //其他操作
   6:         ViewEngines.Engines.Insert(0, new StaticFileViewEngine());
   7:     }
   8: }
1: public class HomeController : Controller
   2: {
   3:     public ActionResult ShowNonExistentView()
   4:     {
   5:         return View("NonExistentView");
   6:     }
   7:  
   8:     public ActionResult ShowStaticFileView()
   9:     {
  10:         return View();
  11:     }
  12: }

我们为Action方法ShowStaticFileView创建一个StaticFileView类型的View文件ShowStaticFileView.shtml（该View文件保存在“~/Views/Home”目录下，扩展名不是.cshtml，而是shtml），其内容就是如下一段完整的HTML。

   1: <!DOCTYPE html>
   2: <html>
   3:     <head>
   4:         <title>Static File View</title>
   5:     </head>
   6:     <body>
   7:         这是一个自定义的StaticFileView！
   8:     </body>
   9: </html>

（参考引用：http://www.cnblogs.com/artech/archive/2012/08/23/view-engine-02.html）

ASP.NET MVC的流程讲解

时间： 2024-11-16 00:47:54

ASP.NET MVC的流程讲解的相关文章

ASP.Net请求处理机制初步探索之旅 - Part 5 ASP.Net MVC请求处理流程

好听的歌 我一直觉得看一篇文章再听一首好听的歌,真是种享受.于是,我在这里嵌入一首好听的歌,当然你觉得不想听的话可以点击停止,歌曲 from 王菲 <梦中人>: 开篇:上一篇我们了解了在WebForm模式下一个Page页面的生命周期,它经历了初始化Init.加载Load以及呈现Render三个重要阶段,其中构造了页面控件树,并对页面控件树进行了大量的递归操作,最后将与模板结合生成的HTML返回给了浏览器.那么,在ASP.NET MVC模式下,一个页面的生命周期又经历了哪些步凑呢?别急,本篇漫漫

ASP.NET MVC 请求流程：Controller

1.请求进入时,.NET Framework就找出所有的HttpModule,以此调用它们的Init方法,如下图所示,我们重点关注"UrlRoutingModule-4.0"的HttpModule. 2.我们看看UrlRoutingModule方法中做了哪些操作 . 继续往下看 我们来到了PostResolveRequestCache方法中,我们进入RouteCollection.GetRouteData()方法中看下,如下所示 看过上节的同学会知道这里的routeData就是Syst

ASP.NET MVC 请求流程

一.应用程序启动 1.Application_Start方法,程序启动 2.RegisterRoutes方法,注册路由 3.System.Web.Mvc.RouteCollectionExtensions.MapRoute方法,出现了MvcRoutehandler对象 二.请求进入 在 “$\Windows\Microsoft.NET\Framework\版本号\Config\Web.config“ 中可以找到 " ” 证明请求会经过System.Web.Routing.UrlRoutingMo

在ASP.Net MVC 中如何实现跨越Session的分布式TempData

Hi,guys!Long time no see! 1.问题的引出 我相信大家在项目中都使用过TempData,TempData是一个字典集合,一般用于两个请求之间临时缓存数据或者页面之间传递消息.也都知道TempData是用Session来实现的,既然是用Session来实现的,那么模式就是线程模式,这样的Session是没法用到分布式系统中的,那么在多台机器上部署,怎么做到Session在多台机器中共存,这就涉及到分布式存储.那该如何实现TempData的分布式存储?在讲如何实现时,先给大家

.NET MVC请求流程

ASP.NET MVC 请求流程:Controller MvcHandler Action Action参数赋值

asp.net MVC 的处理流程

之前把笔记都放在空间日志中隐藏起来,今天看到这句话:作为经常从网上索取免费资料的一员,要有回报的思想,也为了让更多的人少走些弯路,想想自己不能这么自私,所以把空间日志搬到博客园来.闲话不说,直接开始. asp.net MVC 分为主要的Controller .Action.以及Views 下面来分析Asp.net MVC的处理流程: Controller 负责将获取Model数据并将Model传递个View对象,通知View对象显示. 处理流程: 1.用户发起请求--->UrlRouting获取

ASP.NET MVC流程解说

开始想这个标题时,,很忧郁什么标题将得到更好的叫什么,最后确定的解释,虽然稍0基金会,但是,这个概念是非常.我想出了一个相当的价格值的. ,開始. 1.MVC的基本开发流程   2.webform和MVC的选择   3.MVC的内部过程 1.MVC的开发流程 MVC的出现时微软在2009年左右開始提出的站点开发的新的发展方向.这个方面的开发官方解释是能够比較好的实现三层分离,并且分离之后.能够实现复用等相关优点,通常人们列举的样例是ui方面能够同一时候支持HTML网络或者WAP网络.可是事实上个

ASP.NET MVC学前篇之请求流程

ASP.NET MVC学前篇之请求流程 请求流程描述 对于请求的流程,文章的重点是讲HttpApplication和HttpModule之间的关系,以及一个简单的示例实现.(HttpModule又是MVC框架的入口点) 图1 在请求到达Web服务器过后进入ASP.NET的时候是通过ASP.NET来构造出一个HttpWorkerRequest对象,HttpWorkerRequest是抽象类类型,表示着一些请求处理的信息,然后由ASP.NET中的HttpRuntime类型来调用静态函数Process

ASP.NET MVC的请求处理流程

(1)用户打开浏览器,在地址栏输入某个网址URL并回车,浏览器便开始向该URL指向的服务器发送HTTP请求(一般是GET方式).(2)服务器端的网站服务系统(IIS)接收到该请求,先检查自己是否认识该类请求,如果认识就直接处理并发回响应,否则就将该类型的请求发给对应的HTTP处理程序(在此是ASP.NET MVC).(3)MVC路由系统收到请求后,根据HTTP请求的URL,把请求定向到对应的控制器.(4)如果控制器是MVC内置的标准Controller,则启动Action机制:否则,根据自定义的