我最近一直在对不同类型的模型视图架构进行一些调查，并且需要决定在未来的内部开发中追求哪一种。由于我目前在一家拥有 ASP.NET 技能的 Microsoft 商店工作，因此我的选择似乎介于 ASP.NET MVC 和 WCSF 之间（Monorail 可能不适用，因为 Microsoft 不支持它）。
在阅读了 ASP.NET MVC 框架之后，以 WCSF 作为衡量标准，我总结了以下几点：
还有哪些其他考虑？
我误解了什么？
有没有人使用过这两种框架并有任何建议？
ASP.NET MVC 不能使用依赖回发的 Web 控件，而 WCSF 可以。
您应该将 WCSF 视为有关如何使用现有 WebForms 基础架构的指南，尤其是引入 Model-View-Presenter 以帮助实施关注点分离。它还增加了生成代码的可测试性。
与 WCSF 站点相比，您可以更好地控制 ASP.NET MVC 站点中的 url。
如果您可以针对 3.5 SP1，您可以将新的路由系统与传统的 WebForms 站点一起使用。路由不限于 MVC。例如，看一下动态数据（也在 3.5 SP1 中提供）。
一个 ASP.NET MVC 站点可能比等效的 WCSF 版本更容易测试。
这是真的，因为它为 HttpContext、HttpRequest、HttpResponse 等使用了新的抽象类。MVC 模式本质上没有什么比 MVP 模式更可测试的了。它们都是“分离演示”的实例，并且都增加了可测试性。
WCSF 似乎在某些情况下仍然使用背后的代码来控制 UI 事件，但 ASP.NET 不允许这样做。
在 Model-View-Presenter 中，由于外部世界与视图交互（即 URL 指向视图），视图自然会响应这些事件。它们应该尽可能简单，通过调用演示者或提供演示者可以订阅的事件。
Model-View-Controller 通过让外部世界与控制器交互来克服这个限制。这意味着你的观点对于非展示的东西可能会很“愚蠢”。
至于您应该使用哪个，我认为答案归结为最适合您的项目目标的一个。有时 WebForms 和丰富的第三方控件供应商的可用性会更可取，在某些情况下，原始的简单性和细粒度的 HTML 控件将有利于 MVC。
不是要引发一场激烈的战争，但我发现 WCSF 相当复杂。MVC 的优雅和简单让 MVP 印象深刻，它感觉就像是一种刚刚嫁接到 Web 表单上的模式。
在进行完全相同的评估后，我们选择了 WCSF。我们觉得 MVP 模式给了我们更多的选择，即使用服务器控件的能力。我们的开发团队主要由来自各种学科的程序员组成，例如 C++、Biztalk 和 web 等，但都主要专注于 MS 类型的开发，因此采用这些模式的学习曲线对我们的团队来说并没有那么大。
我们对我们的选择感到非常满意。
您还可以考虑开发人员的背景（如果已经确定）。
如果他们来自严格的 asp.net 背景，他们会更适应 WCSF（尽管根据我的经验，他们仍然需要几个星期才能真正适应 MVP）。
如果他们来自 java/rails 背景，或者以前使用过其他 MVC 架构，那么显然他们会在那里更快乐（根据我的经验，他们对 MVC 以外的任何东西都非常自负）。
MVC 是一个更简单的范例，并且更类似于所有其他框架进行 Web 开发的方式。WebForms 只是太多的跳跃和太多的抽象层来尝试实现简单性。恕我直言，MVC 将在几年内成为默认的 ASP.NET 架构，因为越来越多的人意识到它为我们带来的开发和测试的简单性和易用性。我已经从事 MVC 开发一年半了，甚至从未想过要在新项目上回到 WebForms。
一个 ASP.NET MVC 站点可能比等效的 WCSF 版本更容易测试。
这是真的，因为它为 HttpContext、HttpRequest、HttpResponse 等使用了新的抽象类。MVC 模式本质上没有什么比 MVP 模式更可测试的了。它们都是“分离演示”的实例，并且都增加了可测试性。
这可能值得商榷，但有文献表明，如果您有包含逻辑的视图，则使用 MVP 设计模型比 MVC 设计模型更容易进行单元测试。总而言之，在 MVP 设计模型中，Presenter 正在处理可能由 MVC 设计模型中的 View 处理的工作。MVC 视图中可能包含的逻辑不利于单元测试。以下是我读过的一些参考文献，它们涵盖了这个概念，以及为什么保持 View light 更好的原因有很多，包括促进单元测试。
http://martinfowler.com/eaaDev/uiArchs.html
为什么不将两者都附加到 Northwind，看看哪个最适合您和您的情况？