ASP.NET 为什么要有 MVC

　　不得不承认，最初MVC并没有被微软的研发人员设计到ASP.NET中。至于为什么非要在后来强行加入到ASP.NET中，我们无从得知。
　　不过在类似Java平台中的Struts之类的MVC框架如火如荼的发展，而且被很多新老技术人员给它们套上了一层层神圣的光环，如果微软没有采取一些行动，确实有些丢这个“软件帝国”的面子。

软件帝国的超级武器——WebForm
　　WebForm——确实是一个非常有创意，并且非常实用的东西。不过可以肯定，不管是现在，还是在不远的将来，WebForm都将会一直保持着它独具的特色，和它无于伦比的便利性。
　　在WebForm中，微软开创性的将桌面应用程序的开发模式引入Web应用程序的开发中。例如拖控件、加事件处理程序、然后运行……这一切都是那么的惬意、那么的让人拍案叫绝。
　　而且，ASP.NET还可以将前台的视图展示代码和后台的事件处理程序完全隔离在两个不同的文件中。如此，一切看似神奇的东西都被系统“自动”完成了。
　　这一切，对于一个初级的Web程序开发人员来说，比让其编写大堆的页面代码要舒服的多。所以ASP.NET WebForm一度吸引了无数的开发人员加入进来。

超级武器也有盲区
　　回到上个世纪，大部分的Web应用都是使用的页面中混合代码的数据编程。比如ASP和PHP（早些时候）一样直接在页面中向数据库请求并用HTML显示的程序结构。这种方式往往开发速度比较快，但是由于数据页面的分离不是很直接，所以很难体现出程序业务模型的样子，当然也很难实现模型的重用性。产品设计没有弹性，很难满足不断变化的用户需求。
　　不过这些缺陷，都被JSP和ASP.NET这两种天生就面向对象的语言很好的解决掉了。现在一般的应用程序都使用三层（或多层）结构来处理程序中的业务逻辑。
　　在Web应用程序的界面层，经常需要在不同的时刻为不同的用户呈现不同的内容。所以能不能把这个对“不同的时刻”、“不同的用户”、“不同的内容”的判断和具体的内容进行分离，使之更容易的控制和协调就成了一个新的问题。
于是乎，Java随即就引入了MVC模式的应用框架，很完美的解决了这个问题。
　　而与此同时，ASP.NET却在专注于WebForm的研究和应用，同时也取得了一些非常可观的成就。但是其极大程度的整合了MVC模式中的V和C的关系，虽然独具特色，却使应用程序的UI层耦合性加强，或者说有点与MVC的思想背道而驰（或许这么说有点贬意，不过这里的确没有贬低WebForm的意思），惹了不少开发和测试人员的抱怨。

 软件帝国的快速反应
　　正值Java中的MVC框架快速发展，同时ASP.NET WebForm也大行其道的时候，微软推出了ASP.NET MVC框架。
　　也许是因为Java中的MVC发展的太火了，微软有点像是在跟风的意味，于是很多人就开始有点见风使舵，大呼ASP.NET将迎来WebForm的末日、MVC的新纪元，这样其实是毫无依据的。
　　首先，MVC和WebForm根本就不具可比性，WebForm是一个全新的Web开发模式，从头到尾都是套完整的东西。虽然其在某些方面有一些局限性，但是其仍然是一个优秀的开发模式，是MVC不可取代的。
　　其次，MVC和WebForm各有所长，MVC主要解决的是视图层的耦合性问题，但是其不具备快速开发和简单易用的特性，需要开发人员掌握的知识比较系统全面；而WebForm却简单易用，入门非常容易，其具有MVC不可替代的位置。
　　总之，MVC和WebForm不会冲突，也不会有那一方很快消亡（除非那一天有谁整合了它们二者的优点到某一方上面）。
　　而且当下据微软对二者的态度来看，似乎应了*先生说过的一句话——“两手抓，两手都要硬”。

其它

　　说一点可能让Java程序员心里不爽的话：学了ASP.NET，感觉非常好（虽然它很“年轻”），它直接解决掉了许多Java中的诟病，比如像长篇小说似的配置文件……

（注：本文的一部分观点和语言是借鉴某网友博客的，具体是那儿的记不清了）

 （转载请注明出处：http://www.cnblogs.com/zhhh/）