Rick Strahl在他对ASP.NET平台下的Web Form和MVC框架的观察中首先谈到了Web Forms的强大之处。他提到，Web Forms已经被证明是一个非常稳定和成熟的平台。即使在性能要求非常高的情况下，它也不太会出现扩展方面的问题。同时，Rick还认为从Web Froms入门Web开发是一件非常容易的事情。
微软设计了一个完整Web开发环境，使得构建Web应用有了新的体验，开发人员只需在一个可视化设计器中拖放控件、并且在表单中设置属性即可。与此同时，开发人员可以编写代码来响应事件，这使得对于程序逻辑的操作变得非常直观，就好像并非在开发一个Web应用一样。Web Forms模型提供了一个高度抽象的框架，使得入门变得非常容易。但是它也容易造成一些问题，因为它在很多方面将开发人员和低端的Web机制隔离开来。我稍候将回过来再谈一下这个次要的问题。
他在总结中谈到，这个框架有着非常强大的扩展能力，并且肯定了它对自定义控件这一产业所做出的贡献（可能ASP.NET控件厂商比其他平台下的总和还要多）。
对“高度抽象”进行了褒扬之后，Rick开始阐述它的缺点。
这既是一种幸运也是一个祸根。Web Forms让开发人员能够轻松地拖放控件，并且通过响应页面和控件的各种事件来快速开发Web应用。这一点很不错，但是首先这种高度的抽象使很多开发人员完全忽略了——甚至从没有了解过在这背后HTML是如何运作的。这往往会产生无法通过校验的HTML代码，或者是一些非常冗余，难以管理的HTML布局，这对于页面设计人员非常不友好。同时，如果没有合理控制ViewState的话，你很容易得到一个包含大量ViewState的页面，它的尺寸远远超过所需的内容，最终使得页面打开异常缓慢。
Web Forms框架的缺点之一，就是微软在这个抽象背后构建了一个非常复杂的引擎，它给页面的执行过程带来了许多的负面效应。如果你曾经构建过包含大量组件的复杂页面，就会发现某些时候要协调好数据绑定，页面生成等事件的顺序，并且在页面的生命周期中选择恰当的时间来设置不同的控件是一件非常困难的事情。你是否曾经在Init、Load或者PreRender事件中加载过数据？你是否在PostBack事件中进行过赋值？Web Forms需要服务器端的一个独立的表单中进行操作，因此你可能无法轻易地将它分解成小的逻辑单元。在一些复杂情况下，事件处理程序会变得非常庞大，你很难对它们的工作进行重构，最终你会得到许多难以维护的代码，并且几乎无法进行测试。
他继续详细讨论了ViewState，事件管理和PostBack机制的问题。对于这些内容还没有做到了如指掌的ASP.NET开发人员应该通过文章内容再努力学习一下。
有个问题可能会使非.NET平台的开发人员感到非常惊讶：我们很难在设计期间就确定一个控件的ID。由于文档中少有提及的命名容器链（Naming Container Chain）存在一定的缺陷，我们只有在运行时期才能知道“txtPassword”控件最终会获得一个形如“PublicSiteTemplate1_ctl00_txtPassword”的ID。而在使用其它技术开发的普通页面中，这应该是一个相对较短的ID。
含糊不清的控件ID以及ViewState对于如今的Web 2.0站点来说都是严重的问题。唯一不会受到ViewState带来的负面影响的框架是ASP.NET AJAX，但这还是一个不成熟的类库。（译者注：事实上，如果您使用了ASP.NET AJAX中的UpdatePanel控件，在客户端与服务器端交互的过程中依旧需要传递页面上所有的ViewState。另外，2006年最佳个人定制页面网站www.pageflakes.com，也是基于当时的ASP.NET AJAX框架开发的，并且集成到.NET Framework 3.5中的ASP.NET AJAX又在各方面有了更进一步的改进，如果武断地称之为一个不成熟的类库未免有失偏颇）。
对我来说，Microsoft AJAX总体上无法成为我的首选客户端框架。它体积很大，并不十分模块化，而且对于客户端开发人员来说，一个本应该包含更多有用核心功能的客户端脚本框架，它提供的功能又非常有限。如果你将它和jQuery，Prototype，MooTools等包含强大功能的类库相比，感觉Microsoft AJAX严重缺乏一些在实际使用中有用的功能。同时，它包含的控件构建模型又显得死板而复杂，这些都无法成为选择Microsoft AJAX的理由，除非你想使用UpdatePanel或者AJAX Control Tookit中的服务器端控件。
接着Rick又谈到了Web Forms开发人员很容易将业务逻辑和表现层逻辑混合在一起。虽然使用Web Forms也可以将两者很好的分开，但是做到这点需要遵守相当数量的规则。
对于专业人员来说，Web Forms难以测试是一个更大的问题。Web Forms几乎无法做到自动测试，一部分原因是由于我们很难模拟Context、Response和Session对象，至于其他的原因还有例如我们很难处理它的事件驱动模型等。
MVC框架完全将这些缺点抛至一边，因为它舍弃了Page类和其他相关的负担。Rick是这样描述它的：
微软创建了另一种Http Handler来实现MVC框架，所以它完全与Page类无关，也避免了很多Web Forms框架所带来的复杂性。MVC框架的一个关键特性是提供了一种为特定任务生成内容而创建自定义视图（View）的能力。而控制器（Controller）负责使用各种模型来完成应用的核心任务，然后为视图提供生成页面内容所需的数据。例如，我们很容易想到为RSS或者其它XML输出的数据，亦或是类似登陆框或者出错页面来编写可复用的视图。然而，在默认情况下，生成视图的输出内容依旧使用了ASPX页面：ViewPage类。它基于Page类，但是并不会直接被HTTP Handler执行，而是被MVC引擎用作内容生成器，这比在完整的Web Forms框架中运行传统的ASPX页面要显得轻量了许多。
我们还是可以使用Web Forms框架中的部分控件和一些技巧，不过前提条件是它们不能依赖Post Back。和在页面中使用控件的传统开发方式不同的是，开发人员会发现他们需要使用大量的内联代码，就好像传统的ASP应用一样。
MVC模型在工作时是通过URL来选择应该执行哪个指定的控制器方法，并且任何的操作都会被引导至控制器中的特定方法。微软开发的引擎使用了类似Ruby（译者注：确切的说应该是Rails框架，Ruby只是一种开发语言）的机制来解析干净的URL（例如http://localhost/Customers/Show/1），并且根据URL的格式将它们引导至特定的控制器，这种引导机制——就像MVC框架中的大部分东西一样——能够被很轻易地重新定义，这样你就能够使用不同的URL语法来将引导至特定的控制器。
同时，Rick发现一些有趣的东西，因为事物在过去十年中的发展形成了一个循环。
Web Forms模型曾经是.NET平台下Web开发最钟意的方式，在这个讨论中谈到这点显得多少有些有趣。事实上，我觉得有些讽刺的是，MVC框架在一定程度上回到了传统的ASP风格，那便是直接使用脚本来手动生成HTML的开发方式，而现在只是提供了一种更为严格的做法来将这种开发方式和代码逻辑区分开来。我还记得在早些时候，那些ASP.NET的疯狂追随者们是多么不屑使用内联的脚本标签，或者使用显式的URL而不是PostBack来进行开发的做法，而其中的一些人现在又毫不犹豫地张开双臂去迎接MVC框架，这难道不讽刺吗？
现在要确定MVC框架是否真正满足大多数Web开发人员的需要还为时过早。从现在所表现出来的结果上看，即使是开发简单的页面，MVC框架也需要大量的代码。我看过早期版本的MVC框架，但是并不清楚如何才能有效地编写一些更加复杂的页面，除非编写大量的选择语句来引导代码，我很难确定究竟页面上的哪一部份需要更新。以前我曾经开发过几个和MVC框架运作方式比较接近的Web开发框架，根据我的经验，它们总能很轻易的用于简单的页面开发，但是一旦页面上需要出现各种不同的、且相互独立的组件时，这些做法都逐渐出现问题了。使用基于无状态的控制器的做法来管理复杂度高的应用，要比目前Web Forms框架提供的功能要困难许多。至于这个框架会如何发展，以及最终会形成什么样的模式来处理复杂任务，我们都还需要拭目以待。如果关注一些Java或.NET平台下已经出现一段时间的MVC开发方式并加以比较，则可能会带来不小的帮助。
最后，Rick是这样总结的：
到目前为止，我还没有打算将所有的希望押在一个新出现的，还没有被证明成功的框架，因为这好比连小孩和洗澡水一起倒了。Web Forms还是有许多优点，微软现在只是决定尝试一些新的事物，但这并不意味着我们必须完全转向它们。毕竟MVC框架出现的时间还不够长，现在还不能算作久经考验。虽然MVC框架很快就会吸引一批开发人员——但是对于其余像我们这样的人，微软还必须给出一个无比强大的框架，它至少需要能够在灵活性，扩展性和可用性等方面和Web Forms相媲美。有趣的事情还在前面，我也会兴致勃勃地关注它们……