Java中的MVC:
◆View (JSP) 只纯粹用来生成输出，不涉及数据来源的访问、事件处理、各种逻辑处理和运算工作。因此更适合大型项目的分工，把这层 完全交由美工人员制作 (而非程序员兼美工和排版)。此层如同 ASP.NET 中的 .aspx 前台页面，亦即 UI (User Interface)。
◆ Model (JavaBean、EJB 组件) 用来存放独立且可重复使用的组件，包括：数据来源 (数据库) 的访问、商业逻辑的代码，并应与 View 作完整地切割，以便保留系统日后扩充或改写时的弹性。此层如同 ASP.NET 中的 App_Code 文件夹中的自定义类、DataSet (.xsd)、 TableAdapter、…等等。 【这个和三层中的Model是不同的概念】
◆ Controller (Java Servlet) 用来控制整个网站处理的「流程」，负责协调 View 和 Model 之间的流程传递和转向，也要管理和指派由 哪个文件去接收用户所提出的「请求 (request)」，亦即由它决定要展现哪一个 aspx 文件给用户。当用户从浏览器送出 request 时 (例若用 鼠标单击页面中的控件，或输入数据后单击 Button 的提交、输入 URL 网址、点选 hyperlink…等等)，Controller 里定义的某些 method 会 判断要交由Model 中的哪些运算逻辑去处理，然后再判断要将处理结果传回哪一个 View 去显示出来。
此外，Controller 还可包含错误处理、授权、输入验证…等功能的代码，集中统一处理，以避免传统 WebForm 里大量重复的代码。但说穿 了，Controller 事实上只是一个自定义类，搭配一些 Attribute (特性)。而 Controller 也是目前 ASP.NET 所欠缺的部分。
更多介绍：http://developer.51cto.com/art/200904/120649.htm
ASP.NET MVC——螺旋进步的产物对于微软为什么要推出ASP.NET MVC，我们是无从得知的，也许是因为JavaEE平台上有Struts，也许是因为MVC太流行，也许微软是想使得自己的Web App平台更完善，总之我们只能猜测。但是如果回顾一下微软的Web App平台进化过程，还是很有意思的。ASP——微软最早为Web开发做出的贡献可能就是ASP了，这个动态语言把动态网页开发的难度空前降低了。但是，在很多人兴奋的用ASP写着一个又一个动态网页时，它的缺点渐渐暴露：语言过于简单，没有面向对象支持、没有好的IDE支持、动态脚本和静态HTML杂糅在一起，使得修改及维护极为困难。Web Form——说实话，即使是用现在的眼光看，微软推出的Web Form编程模型确实是很有创意，也很实用。微软开创性地将桌面应用的开发模式引入Web应用开发：拖控件、写事件处理、运行...一切都那么美好，而且前段静态代码和后端程序完全隔离在两个文件里，并且用户可以使用.NET平台上任意一种语言进行后端编程。对程序员来说，使用C#进行编程比使用ASP实在是舒服太多了。所以，Web Form模型可以说成为.NET Web App开发的代名词，所有基于.NET平台的Web开发人员都熟悉并接受了这种模型。ASP.NET MVC——就在Web Form大行其道时，微软推出了ASP.NET MVC。严格说，ASP.NET MVC和Web Form是不具有可比性的，Web Form是一个完整的新型模型，从顶层到底层是一整套的东西，而ASP.NET MVC只是给Web Form穿了件MVC样子的外套，它应该是基于Web Form的一种编程方式模型扩展。但是，从开发人员看，ASP.NET MVC的推出确实大大改变了我们的开发方式，很多Web Form下的方式不被提倡了（你仍可以用，因为ASP.NET MVC也是基于Web Form的），例如，曾饱受赞扬的服务器端控件再度被抛弃，转而再次使用客户端控件，事件驱动模型被抛弃，转而使用了类似传统的Url跳转处理模型。而且在数据验证等方式上与Web Form下提倡的方式有了很大变化。如此看来，真像是一个轮回，似乎ASP.NET MVC又把我们带回到了ASP时代：服务器端模型不让用、事件驱动机制不让用、类似Desktop App的开发方式不让用...我们似乎从Web Form回到了传统的ASP时代。但是，真的是这样吗？当然不是！只要稍微用一下，就知道虽然ASP.NET MVC提倡我们废除Web Form下的很多东西和习惯，但是绝不是让我们“回归原始”，如果非要说是一个轮回，那也应该说是一个螺旋式的轮回，是上升式的轮回。记得马克思主义哲学中有个很经典的命题：对于新事物来说，道路是曲折的，前途是光明的。也许，Web App模型的发展就印证了这个观点吧。也许，服务器端控件、事件驱动模型这些东西一开始就是不适合Web App的，微软走了很多弯路，现在找到了正确的方向。抛弃的痛苦的，我们要抛弃曾经认为多么习惯并且倾注了大量心血的东西，但是，事物被否定后，剩下的的一个蜕变出的新事物，是一个更优秀的东西。例如，我们抛弃了用了多年的务器端控件、事件驱动模型……但是我们得到了低耦合的、关注被分离的、符合MVC模型的新的Web模型。要敢于否定，才能获得新生。微软是，我们也是。ASP.NET MVC带来的变化下面，我们看看ASP.NET MVC到底让我们否定什么？又能得到什么。1.服务器端表单控件。由于ASP.NET MVC的特质，服务器端的表单控件不再被提倡使用，例如我们的文本框，不再使用asp:TextBox，而是使用传统的input，或直接让Html.TextBox生成。总之，很多服务器端控件被我们废止了。甚至GridView这样曾给我们带来无限快感的老朋友，也不再被提倡使用。但是，并不是说不能用任何服务器端控件，例如，为了实现母版，我们的ContentPlaceHolder还是必须要使用的。2.事件驱动模型。既然服务器端表单控件已经不提倡使用了，事件驱动模型自然也不被提倡，两者本来就是相辅相成的。在ASP.NET MVC中，当某个按钮被点击，你不要再习惯性想到应该在相应的aspx.cs中有个事件处理方法，你应该想到的是该有某个Controller中有个Action来处理这个事件。实际上，在ASP.NET MVC中，提倡不要在aspx.cs中写任何逻辑代码。甚至应该当他们不存在。3.数据绑定对于列表式表格数据，你一定习惯了GridView的数据绑定，可是，从你使用ASP.NET MVC开始，这不在被提倡了。你应该自己处理数据的显示。当然，我们也可以期待未来的ASP.NET MVC正式版中会有一个强大的Helper来帮我们做数据显示。ASP.NET MVC的收益你一定想知道，我们为使用ASP.NET付出了如此惨烈的代价，那么我们能得到什么？从我个人认为，你至少得到了以下东西：1.清晰的、关注被分离的代码；2.更容易的测试及维护；3.更符合MVC的表示层；4.你可以向Java程序员自豪的说：我现在也用MVC模式了，而且不用写任何XML！
ASP.NET MVC特色与优点
MVC (ModelViewController)把一个web应用分成了三个部分：model view和controller。ASP.NET MVC框架提供了一个可以代替asp.net web窗体的基于mvc的应用。 ASP.NET MVC概述·mvc的优点：
1.通过把项目分成model view和controller，使得复杂项目更加容易维护。
2.没有使用view state和服务器表单控件，可以更方便的控制应用程序的行为
3.应用程序通过controller来控制程序请求，可以提供丰富的url重写。
4.对单元测试的支持更加出色
5.在团队开发模式下表现更出众
web窗体的优点：
1.采用事件驱动模式来控制应用程序请求，由大量服务器控件支持
2.采用页面控制机制，可以为单个页面添加事件处理函数。
3.使用view state和服务器端页面，使管理页面状态信息更加轻松。
4.对人数较少的想使用服务器端控件的开发团队，使用起来更加方便
5.开发起来比mvc模式要轻松简单一些
ASP.NET MVC概述mvc框架特色：
1.分离任务（输入逻辑，业务逻辑和显示逻辑），易测性和默认的测试驱动组件。所有mvc用到的组件都是基于接口并且可以被mock对象测试到，你可以不必在asp.net进程中运行controller就可以使用测试。使得测试更加快速和简捷。
2.可扩展的简便的框架。mvc框架被设计用来更轻松的移植和定制功能。你可以加入自己的视图引擎，url重写策略。重载action方法等。mvc也支持Dependency Injection (DI) and Inversion of Control (IOC）
3.强大的url重写机制让你更方便的建立容易理解和可搜索的url。url可以不包含任何文件扩展名，并且可以重写url使其对搜索引擎更加友好。
4.可以使用asp.net现有的页面标记、用户控件、模板页。你可以使用嵌套模板页，嵌入表达式<%=%>,声明服务器控件、模板，数据绑定、定位等等。
5.对现有的asp.net程序的支持，mvc让你可以使用如窗体认证和windows认证、url认证、组管理和规则、输出、数据缓存、session、profile、health monitoring、配置管理系统、provider architecture特性。
5.1 MVC的优点
MVC的优点表现在以下几个方面：
（1） 可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。
（2） 视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。
（3） 模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。
（4） 潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。
5.2 MVC的不足之处
MVC的不足表现在以下几个方面：
（1） 增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
（2） 视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
（4） 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
我的理解：
MVC底层BLL,DAL一样用。
1 UI表示层优化了，集成了伪静态配置，更好的url
2 用html控件不是基于事件，而是基于请求,根据action。页面中减少了viewState产生的代码
更利于seo
M-Model模型(处理业务逻辑,相当于三层中的BLL) V-View试图 C-Controler控制器。http请求响应过程。浏览器发出Get请求(虚拟路径,有利seo的路径)，经过Controller筛选，就是URL重写.到一个真实的物理路径，这时Controller请求Model,Model访问数据库，获取数据返回给Controller,Controller通过返回类型为ActionResult的方法,return View();返回ViewResult(ViewResult : ViewResultBase ViewResultBase : ActionResult子类的子类)的数据.在View,就是aspx页面中通过<%:ViewData["Title"] %>绑定.
