• 推荐
  • 评论
  • 收藏

Asp.Net MVC3 简单入门第一季(二)详解Asp.Net MVC3项目

2022-12-05    4951次浏览

前言

在上一篇文章Asp.Net MVC3 简单入门第一季(一)环境准备中我简单介绍了Asp.Net MVC3项目的安装和第一个Asp.Net MVC3项目的基本情况。没有详细介绍项目中各个文件夹的作用,以及创建的第一个页面是怎样运行起来的?还有好多的疑问,那在这篇文章中我们将详细介绍项目中各个文件夹的作用,并真的第一个项目我们简要介绍一下Asp.Net MVCURL驱动的是怎么回事。 

第一节:Asp.Net MVC3项目介绍

让我们先看一下,一个普通的Asp.Net MVC3项目的样例,如下图所示 

 

跟WebFrom还是有区别的,如果你已经了解Asp.Net MVC2的话,那就感觉异常熟悉了!但还是有些区别的。不管怎样我们都一一介绍一下。 

很有意思的事情是即使我们创建一个空的MVC项目,VS也自动帮我们创建以上图所示的目录,这是为何呢?这是由于MVC秉承了“约定大于配置”的思想,我们在使用Asp.Net MVC3开发项目时也要注意,一定要按照它的约定办事,比如:Controller在返回Action后需要一个View进行展示(当然是调用了View()方法时),这时候Asp.Net MVC回到Views文件夹下找到Controller名字相同的文件夹下面找到具体的页面进行渲染,当然如果找不到会去Shared文件夹下去找。看下表所示的就是Asp.Net MVC3中各个文件夹的作用。 

文件夹

作用

/Controllers

存放控制器类【职责是:处理用户的请求,指挥具体的页面进行渲染交给客户端】

/Views

存放各个控制器对应的视图文件,如果是Razor引擎的话那后缀是cshtml.如果使用的WebFrom的视图引擎的话,那还是Aspx后缀。

/Content

主要存放照片、CSS、Flash等文件

/Scripts

主要存放脚本文件【微软默认给我们提供了JQuery1.5.1的包,看来JQuery已经成为默认的工业标准了!我们没有退路了,呵呵,当然我个人也非常喜欢JQuery】

/Models

主要存放ViewModel类【当然这个不是严格这样要求的,而是推荐你这么做。】

其他的几个比较有意思的文件:

一个是Web.Config,另外一个是Global.asax虽然我们大家都非常熟悉,但是跟之前我们WebFrom 还是有很多的区别的。WebConfig文件中,配置了启用客户端脚本验证、配置了System.Web.Routing、System.Web.Mvc 等组件。而Global.asax则在应用启动的时候注册了全局的Area【区域,后面会相信讲解】、全局Filter、路由等。

第二节:Asp.Net MVC的请求处理模型

在上一篇中我们也简单做了个小例子,直接添加一个Controller,然后在Action上添加一个View,直接运行,然后就在我们面前呈现了一个普通的Html页面。那我们详细解释一下这种开发方式或者说开发模型。在讲解之前我们先认识几个概念:

Controller:控制器。在Contrller文件夹添加的以Controller结尾的类就是控制器, 它的每个方法就是一个Action。它的职责是从Model中获取数据,并将数据交给View,它是个指挥家的角色,它并不控制View的显示逻辑,只是 将Model的数据交给View,而具体的怎样展示数据那是View的职责,所以Controller跟View是一个弱耦合的状态,而且 Controller可以任意指定具体的View进行渲染。所以达到了UI层的代码和实体良好的分离。

View:视图.负责数据的展示,当然这个视图代码的编写应该是更接近纯净的Html的,而View层代码的书写又直接跟视图引擎解析的规则有关,所以Razor的语法跟webFrom视图引擎的语法截然不同。而笔者更倾向更喜欢Razor语法的简洁、方便。

Model:很多人把Model理解成领域模型,而MVC本身是一个表现模式,它是更倾向于UI层的一个框架,所以一般我们指定的Model呢在使用时一般作为ViewModel来用,但是总的MVC的思想呢,Model还是领域相关的东西吧。

经过MVC3个模块的了解分析,我们大体也知道了Asp.Net MVC的一些基本的概念。接下来我们分析一个完整的Http的处理过程。看下面一个图:

 Asp.Net MVC请求处理响应原理图

客户端发送一个Http请求,首先被我们的IIS捕获到,然后根据Url请求的格式,最终交给我们的Route组件,然后它负责解析出我们的Url 具体请求的是哪个Controller下的哪个Action。然后MVC经过处理调用我们的Action执行。在Action中我们一般会从业务的 Façade层取出数据,然后将传输层的数据转换成ViewModel再交给View的视图引擎渲染,最终生成Html的字节流写回客户端。

回到我们第一个项目中的情况是,请求:Http://localhost/Home/Index请 求过来,由Route组件解析出Controller是Home,Action是Index,则通过工厂创建一个Controller的实例,然后调用 InvokeAction方法,执行Index的方法,最终执行View()方法返回一个ViewResult实例,再调用自己的 ExcuteResult方法,将数据上下文和输出流交给视图引擎,然后最终渲染成Html页面交给客户端,最终就看到了我们的第一个页面。

总结一下:

Asp.Net MVC所有的请求都归结到Action上,而且Asp.Net MVC请求--处理--响应的模型非常清晰,而且没有WebFrom那种复杂的生命周期,整个请求处理非常明晰简单,又回归到了最原始的Web开发方式,就是简单的请求处理响应!

记于:2011年6月12日23:45:26

作者:FlyDragon

出处:http://www.cnblogs.com/fly_dragon/

关于作者:专注于微软平台项目架构、管理和企业解决方案。如有问题或建议,请多多赐教!

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,如有问题,可以通malun666@hotmail.com 联系我,非常感谢。

原文地址:https://www.cnblogs.com/Leo_wl/p/2079409.html