我记得我曾问过Scott Hanselman，what is the thing that ror can do but asp.net ca not do. Scott说，貌似没有。的确是这样，表面上看，是asp.net mvc 和 ror 之争，其实是微软平台和开源平台之争。 表面上看是asp.net webforms 和 asp.net mvc 之争，其实是不同的实践之争。如同海尔空调绝对不是因为比格力空调多了一个功能而作为卖点，反过来也是。
而且，理解这一点非常关键。如果你一直抱着MVC比ASP.NET Web Forms好的观点，或者下意识比较两者，将两者互为替代品在选择的时候，这种观点使得你使用ASP.NET MVC会出现大问题。一方面你会发现那些信口跟你说MVC如何如何好的人说的优点要么在你用的时候，优点不明显，要么你发现这些所谓的优点是很多缺点换来的。很多很多初学者学习MVC框架遇到最大的问题就在于，他们试图在MVC框架上找回ASP.NET WebForms上原有的东西，因为他们的想法是，既然MVC是WebForms的替代品，尤其是更好的替代品，那么WebForms上有的，MVC上就一定要有，否则就是MVC不好。我记得你问过很多这样的问题，比如怎么使用下拉控件，比如怎么往客户端回写JS脚本实现消息框弹出，这些问题会让你越发郁闷，没准最终让你发现MVC真的很难学，为什么MVC那么难用。而且陷入恶性循环，你越要把MVC改造成WebForms的替代品，你会发现越困难。事实上你遇到的困惑正说明现在讨论这个问题的必要性和价值。MVC作为WebForms的替代品来说它只有坏处没有一个好处。就像你把火锅当作烧烤的替代，问吃火锅的时候怎么搭烧烤架子，怎么排油烟，调料里面孜然竟然不是默认提供的还要找，你发现火锅的好处了么？严重地说，因为火锅店没有提供叉子和烤炉，你要在火锅店吃烧烤可能最后什么也吃不到。
仅仅针对OOAD领域,
MVC的V既可以是asp.netMVC,也可以使asp.netWebForm,也可以是winform,SL,或者html+js
更换一个UI平台,不需要修改M和C
只需要更换对应的视图驱动器(就好比是换个显卡).当然你可以同时像pc和移动客户端提供同一种业务的服务(这就好比同时使用多个显卡或者多个显示器)所以说,asp.netMVC根本就不是MVC,只不过名字中含有这些字母,
当初还害的我们把自己的MVC系统的命名空间修改,以避免和微软的命名的冲突
应该说,这些技术为我们从业者提供了最佳设计的典范,活教材
Scott说，貌似没有。的确是这样，表面上看，是asp.net mvc 和 ror 之争，其实是微软平台和开源平台之争。
表面上看是asp.net webforms 和 asp.net mvc 之争，其实是不同的实践之争。如同海尔空调绝对不是因为比格力空调多了一个功能而作为卖点，反过来也是。
讨论MVC思想的时候,我很少去讨论UI的东西,
因为UI是数据无关,业务无关的,
谈OOAD基本上不涉及这些,
大部分用过程语言比如ASP、PHP开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。
首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。 其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。
再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。
最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。MVC的不足
MVC的不足体现在以下几个方面：
（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
（4） 目前，一般高级的界面工具或构造器不支持MVC架构。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
开发效率随着项目的增加而呈指数级增加,
当企业库稳定后,就很少需要编写代码了
http://www.cnblogs.com/zwycool/articles/462474.html
只不过这个例子看来是临时写的,作者没有透露他们的企业库下面这个链接的观点虽然我不完全认同,但至少是在讨论MVC理论,而不像CSDN很多讨论不着边际:
http://www.cnblogs.com/ego/archive/2009/03/06/1404328.html
老板说，那么明年在给你涨工资吧。
前台为中间层传递参数，并接收中间层的参数；数据库通过中间层来连接并进行相关操作。
MVC三层分为：表示层、业务层、数据层，分别实现：提供应用的用户界面；实现应用程序的业务功能；提供对外部系统的访问。有三层的思想，让开发的思路很明确，很方便调用。
MVC和RoR不同，它本身没有任何数据库访问的支持，也不约定某个数据库访问框架，所以你可以用EF也可以用Linq2SQL也可以用ADO.NET或者NHibernate。问MVC操作数据库的效率好比问用微波炉的人是否会写程序。至于什么网站运行效率，也和MVC一点关系也没有。说实话你提的问题都没尤问到点上。你目前要理解的是什么是MVC。
1.通过把项目分成model view和controller，使得复杂项目更加容易维护。
2.没有使用view state和服务器表单控件，可以更方便的控制应用程序的行为
3.应用程序通过controller来控制程序请求，可以提供丰富的url重写。
4.对单元测试的支持更加出色
5.在团队开发模式下表现更出众
ASP.NET MVC概述·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特性。
如果你试图将它和你之前用的东西去比较，比如什么方便URL重写，或者提高效率之类的优点，那些经验丰富的ASP.NET传统程序员会告诉你，这些根本不需要MVC也可以做得很好。
如果你试图说什么便于单元测试，便于敏捷开发之类的优点，他们会说为什么这个算优点？难道敏捷开发就是优点么？
这样就陷入了无休止的毫无意义的讨论中。我想说MVC是你在众多Web开发架构下的选择。对于这个选择的判断应该在你讨论“MVC的好处”之前就得出，而不是相反。我不觉得你的理解差了点，而是你没有耐心看完我说的话。请你务必看懂这样一个比喻：今天晚上我们吃什么呢？吃火锅还是吃烧烤？我们不是因为火锅比有烧烤的优点而选择火锅，或者也不是因为烧烤比火锅有优点而吃烧烤。事实上可能你平时既吃火锅也吃烧烤。恰恰相反，你决意吃火锅，然后你关注的是王府井的火锅和西单的火锅相比有什么优点，比如便宜或者好吃，这个才有可比性。MoneySoft的讨论是偏题的，但是才是有价值的，你可以说ASP.NET MVC作为一种MVC的实现有什么优点，和其他同类方案，比如MonoRails相比，有什么优点。你完全不能拿MVC和非MVC的东西比，如同火锅店水平的好坏决定了你吃这家火锅还是那家，但是火锅的好坏不决定你是吃西餐还是烧烤还是火锅。相反那些围绕你这个问题煞有介事讨论什么MVC优点的人，恰恰他们说的都是废话，抑或不怎么理解MVC的用处只会背书。而背诵的内容同样是那些不经过思考的人说的东西。
那我可以问MVC这种框架相对于以前的框架的有点
这样可以把
如果你对TDD 敏捷完全没有概念，如果你还不清楚什么是Restfull，如果你并非能够清楚理解客户端服务器端会话的本质，停留在所谓“前台后台”的认识水平上，如果你对MVC架构一无所知，你不会存在这种“实际的需求”。对你来说，ASP.NET WebForms才是唯一能满足你需求的东西。为什么说WebForms能满足你的需求，因为你的需求是完全从用户界面的设计角度去理解程序，开发方式就是先想象界面，再安排代码逻辑。（这里说的并不是对这种方式的批判）事实上WebForms的优点就是将Web开发的复杂性完全隐藏起来。使得对HTTP协议、HTML一窍不通的人也能搭建他们的程序。