ASP.NET和ASP.NET MVC比较

事实上在 Java / JSP 常引用的网站开发架构中，还可分为 Model 1 与 Model 2。Model 1 还可分为二至三种，如下：
第一种是将 HTML 和 .NET (Java) code 混在一起，俗称意大利面式的写法，如：ASP。这种 Inline code 最为人垢病的问题是程序可读性低、难以维护。

第二种是由与 .aspx 一对一对应的 Code-Behind code 直接存取数据库，亦即二层式的架构。但这样的缺点是程序代码难以重复使用，且因为逻辑已经写死在固定的页面中，会造成系统日后扩充困难。

第 三种是经由自订类别库、App_Code 数据夹中的自订类或软件组件，去存取数据库，或做商业逻辑的运算 (JSP + JavaBean)。但此种做法仍缺乏流程的统一控管，导致每一支 ASPX (JSP) 都要验证使用者身份、验证 request 的参数、处理 Session、做例外处理，甚至包括 View 里的编码原则、语系设定，都得在每一支 ASPX 对应的 Code-Behind 去处理，也因此不适合大型系统的开发、扩充和维护。这种架构虽然也能做到虚拟式的三层式或多层式架构，但也是目前 ASP.NET 2.0 的极限。

至 于 Model 2，即俗称的 MVC Framework，则加入了 Controller 的部分，将流程及事件交由中心控管，除了可让整个系统的运作流程更为明确，有效切开各层的工作，亦可避免让 View 里的 Code-Behind 去处理 Model 中的数据库存取、商业逻辑运算，也不必再到处撰写「流程传递和转向」的程序代码，而改由中央的 Controller 程序代码 (action method) 来统一控管。

但 MVC 架构也有其缺点，例如开发人员需要另外花时间转换观念及学习 Framework，尤其是 .NET 的开发人员或团队，因为过去较没有 Controller 统一协调流程的观念，势必得重新习惯，将很多原本写死在各个页面中的程序代码，改写进 Controller 里面。而且系统在设计阶段时，即要先协调好各个类别对象彼此间数据交换的格式及做法，因此势必得拉长系统事先的分析、规划时程。但若能有像 Struts 或 .NET MVC Framework 这样现成的框架可套用，则日后开发大型系统时，即可望达到事半功倍的效果。

 

 

MVC优点:

1.大型开发的时候容易维护，扩展性很好。

2.能够对HTML有完全的控制权限，对于前端来说很友好。

3.能够进行单元测试，保证功能的实现。

 

缺点:

1.没有那么多的现成控件使用，开发效率相对较低（特别是对于菜鸟来说）

2.对于大型数据的处理比较难，还是因为没有现成girdview控件。这个控件虽然生成的html结构异常复杂，但是对于处理大量而且复杂的数据来说是很不错的。不过一般网站是很少有这种大量且复杂的数据，很多菜鸟都是用这个大炮来打蚊子，浪费且低效率。对于网站开发来说这个控件应该不推荐使用。

 

刚学的菜鸟和在需要快速开发的情况下用webform就很好。

需要可扩展性,高度控制性情况下用MVC好。但是用这个框架门槛相对较高，如果你只懂asp.net 的webform开发形式的话，因为webform已经帮你做了太多的事情，换句话说你根本不知道真正的web开发是怎么样的。反而精通php,asp的人更容易上手。

 

MVC和webform开发各有各的用途。

但是你不应该使用asp.net mvc框架，如果符合下面几条:

你对多态不是“非常”的熟悉

你不喜欢在这个框架上构建应用程序

你依赖于很多第三方的UI控件

你不喜欢使用开源的程序

 

 

记者：您认为目前WEB企业级开发最大的障碍在哪一方面？如何运用ASP.NET MVC框架来减轻程序员在这一障碍上的压力？

    衣明志：以前曾经对我做过一次视频采访，那次我谈到过这个这方面的一些内容，但是由于标题和部分表述的原因，可能被一些程序员误解了我的意思。其实就像ASP.NET MVC 2相对于ASP.NET MVC 1.0来说，做了这么多的改进，改进的目标是什么呢？很大程度上就是减少不必要的劳动量和潜在风险，提高生产力，让开发人员的精力更多放到业务处理方面（我提到的业务均不是市场人员所说的业务）。所以Web的企业级开发往往最大的障碍是开发人员把太多精力浪费在了非业务核心的方面，比如说数据验证、UI 代码的编写和一些繁琐但没什么技术含量的工作方面。

    新版的ASP.NET MVC的很多新特性都减轻了开发人员不少的工作压力，比如说Html.EditForModel方法，可以直接在View中生成很不错的编辑界面，而且有自动识别能力：bool型的属性，对应的自动生成CheckBox；枚举类型自动生成下拉列表等等。而Controller、Action、Filter 等都给我们带来很多类似的自动机制，减少了很多繁琐无味的工作，使我们可以把更多精力放到核心工作方面去。

通过对MVC的学习，我们可以看到MVC有如下特点：
1) 业务处理与显示分离：ASPX页面与CS代码彻底分离。更好的复用和维护。
2) 服务器端的表单控件不再被提倡使用，取而代之使用传统的input，或直接让Html.TextBox生成控件标签。
3) 没有了事件驱动模型。在ASP.NET MVC中，当某个按钮被点击，你不要再习惯性想到应该在相应的aspx.cs中有个Click处理方法，你应该想到的是该有某个Controller中有个Action来处理这个事件。
4) 没有了数据绑定。如果你习惯了GridView的数据绑定，在ASP.NET MVC中则需要改变思路，你自己动手解决。
5) 增加了地址重写。MVC的Routing组件让我们可以很好的进行URL路由处理。
6) 总体来看，可以理解MVC是基于Web Form的一种编程方式模型扩展，是一种表示层的编程模型方案。

 

MVC工作的优点是显然的，更加有利于理解分层逻辑，把握代码的层次感。Controller到aspx页面之间的过程，已经被框架隔离。至于 Controller或者View页面与Model调用的过程，还是需要自己来把握。ASP.NET的MVC框架实现了Controller代码的单独管理。

　　而看WebForm开发模型，则只在HttpHandler容器中执行，对其进行分层，在大的方面缺乏支持，而只能依靠逻辑上分离。并不是不能分离，而是由一定的局限性。HttpHandler的拦截，是跟访问后缀名有关的。当请求一个页面时，那就是一个Handler，而 WebForm模型实现显示与逻辑分离，才有的是WinForm的事件驱动。

　　显然，事件必须被注册到页面里，比如 Button1_Click这样的代码。而在Button1_Click执行之前，Page_Load方法会被执行。显示代码被写入Page_Load方 法中，那么就会造成需要写额外的废代码，比如if (!Page.IsPostBack)这样的判定。而在Button1_Click执行后需要显示的部分，则比较难处理，写出另一个方法，也是必须要在 Button1_Click里调用的。替代的解决方案是使用Response.Redirect，在一个aspx页面中处理逻辑，处理完就跳转到另外一个 显示的页面。这样做的坏处是，在两个页面中数据很难共享，而跳转是通过标记302来实现，因此多一次请求。

　　而另外还可以通过 Server.Execute，Server.Transfer或者Context.RewritePath这样的处理方式，则两个页面转换是在服务器端 完成，可以共享数据，可以说和MVC框架的处理方式大同小异，缺点是需要手动配置这些重新定向的属性。

　　从以上分析可以看出，MVC框架 具有很强的优越性，而WebForm也不是一无是处，在简单的应用中更加容易开发。WebForm也是可以实现和MVC一样的分层方式，只是处理时需要多 写一些代码而已。而我认为，在用WebForm开发分层遇到的最大问题是页面与页面之间数据的传递问题，而掌握好WebForm中使用服务器端跳转的应用技巧(Server.Execute，Server.Transfer或者Context.RewritePath)进行开发就可以解决数据传输问题，用 WebForm开发比MVC框架更容易理解，不会产生复杂的配置，也是一个很不错的选择。