不得不承认，最初MVC并没有被微软的研发人员设计到ASP.NET中。至于具体为什么非要在后来强加入到ASP.NET中，我们无从得知。
不过在Java平台中的Struts之类的MVC应用框架如火如荼的发展，而且被很多开发人员给它们套上了一层层神圣的光环，微软如果没有推出一些相应的措施，确实有些丢软件帝国的面子。
软件帝国的超级武器——WebForm
WebForm——确实是一个很有创意、很实用的东西，不管是现在，还是在不远的将来，它都将会一直保持着它独具的创意，和它无于伦比的方便性。
微软开创性的将桌面应用程序的开发模式引入Web应用程序的开发：拖控件、加事件处理程序、然后运行……这一切都是那么的惬意、那么的让人拍案叫绝。
而且，ASP.NET将前台的展示代码和后台的处理程序完全隔离在两个不同的文件中，一切看似神奇的东西都被系统“自动”的完成了。
这一切，对于初级的程序开发人员来说，比让其写大堆的页面代码要舒服的多。所以ASP.NET一度吸引了无数的开发人员加入进来。
超级武器也有盲区
回到上个世纪，大部分的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中的诟病，比如像长篇小说似的配置文件……
（注：本文的一部分观点和语言是借鉴某网友博客的，具体是那儿的记不清了）
