MVC相对于WebForm来说更难学习,但性能优于WebForm,比较适合大型项目,开发成本较高,但耦合度低,易于维护,没有太多的现成控件,开发效率较低。对WebForm有基础的人反而不太容易学MVC。
WebForm
的变化1 ,使用
URL Routing
技术:Web程序的URL不再是指向具体的物理页面.aspx,而是指向某个Controller的某个方法。一个典型的MVC架构的程序,其URL可能如下所示:
http://www.mysite.com/Customer/Index
使用该MVC架构的程序其URL不必有文件扩展名。上面这个URL中的Customer
即为Controller
的名字。而Index
是Customer
定义的一个方法名。
2,Web程序的界面.aspx不再使用服务器端的Form:
那么与服务器端的Form相关的Postback以及页面生命周期的事件也不存在了。
3,页面中不再有View State。MVC下将不能使用View State来存储程序状态信息。
4,不再提供依赖于服务器端Form的服务器控件事件,开发人员熟悉的Button_Clicked事件在MVC下将不再需要。
比如说我们现在要访问一个WebForm
站点:www.google.com.hk/Default.aspx
(仅仅是示例)。我们的浏览器和服务器都是做了哪些动作呢?
1)首先浏览器会向目的服务器发送请求报文。
配置过IIS的都知道,网站挂载在服务器上,我们是通过访问虚拟目录的方式访问网站的。这时候目的主机的IIS接收的是访问该虚拟目录下Default.aspx文件的请求;(当然这也是一个非常复杂的过程,包括请求DNS服务器,找到目的主机IP,根据IP地址访问目的主机。复杂的网络过程就不叙述,有兴趣的自己找资料学习);
2)服务器端的IIS软件接收到请求后,把请求交给.NET FramWork
进行处理;
3).NET FramWork
会创建Default_aspx
类的对象,也就是我们所说的页面对象。(在WebFrom
网站创建完,并且编译后Default.aspx
会被编译成Default_aspx
类)
到现在的整个过程都还是Http
请求,IIS的内部机制会去实现一个IHttphandler
的接口,其中该接口实现一个ProcessRequest
方法
该ProcessRequest()
方法会去调用对应页面的Page_Load()
方法
protected void Page_Load(object sender, EventArgs e)
{
//处理的业务逻辑或者是访问数据库的代码
//要输出的Html或者其它内容
}
4)返回给浏览器(包括Html,CSS,Js
等等)
还比如说我们现在要访问一个MVC站点:www.google.com.hk/FirstPage/Default
(仅仅是示例)。我们的浏览器和服务器又做了哪些动作呢?
1)浏览器向服务器发送Request
请求报文(FirstPage/Default
)
2)服务器端的IIS相应Request
请求
3).NET FramWork
根据路由配置,解析URL
,并创建FirstPage
类的对象,并调用相应的Default
方法
public ActionResult Default()
{
return View();//返回给视图
}
4)然后会访问视图文件夹下的Default.cshtml
,返回给浏览器(其中包括html,css,js
等等)
流程的示意图如下:
这只是一个比较简单的运行过程。其实在这过程中发生了很多事情,比如说:执行Global.asax
中的Application_Start()
方法来完成一些初始化的工作等等,会在以后的文章中继续解析。
以上就是WebForm
网站和MVC
网站运行机制的区别。
那么到底使用MVC
的优点比WebForm
到底有哪些优点呢?
①最重要的就是.NET程序员在开发的时候再也不会使用那些被很多人诟病的微软封装的控件了。
②MVC设计模式降低了模型(Model
,业务和数据)和视图的耦合关系。包括我们在开发WebForm
网站使用三层架构的思想也是为了降低数据和视图的耦合等;
③可以复用视图,也就是说同样的数据可以使用不同的视图以不同的图标展示出来。