我最近对模型视图体系结构的不同类型进行了一些调查，并且需要决定为未来内部开发寻找哪一种体系结构。由于我目前在一家拥有ASP.NET技能的微软商店工作，看起来我的选择在ASP.NET MVC和WCSF之间（Monorail很可能不在，因为它不会被Microsoft支持）。ASP.NET MVC与Web客户端软件工厂（WCSF）
阅读the ASP.NET MVC framework, using the WCSF as a yardstick后，我拿起了以下几点：
有什么其他的考虑？
我误解了什么？
有没有人使用过这两个框架，并有任何建议？
ASP.NET MVC不能使用依赖于回发Web控件，而WCSF可以。
你应该想到WCSF作为有关如何使用现有的WebForms基础设施，特别是引入模型 - 视图 - 演示，以协助执行分离关注指导。它还增加了结果代码的可测试性。
你有过在ASP.NET MVC的网站网址，而不是一个WCSF网站更多的控制权。
如果您的目标是3.5 SP1，则可以将新的路由系统与传统的WebForms站点一起使用。路由不限于MVC。例如，查看动态数据（也包含在3.5 SP1中）。
ASP.NET MVC站点可能比等效的WCSF版本更容易测试。
这是正确的，因为它采用了新的抽象类的HttpContext，HttpRequest对象，HttpResponse对象，等有什么本质上的可测试性的莫过于MVP模式MVC模式。它们都是“分离式演示”的实例，并且都提高了可测试性。
似乎WCSF在某些情况下仍然使用后面的代码来控制UI事件，但ASP.NET不允许这样做。
在Model-View-Presenter中，由于外部世界与视图交互（即URL指向视图），视图自然会响应这些事件。他们应该尽可能简单，无论是通过打电话给演示者，还是提供演示者可以订阅的事件。
模型 - 视图 - 控制器通过让外部世界与控制器交互来克服了这个限制。这意味着你的观点可能会对非演示事物产生很大的影响。
至于你应该使用它，我认为答案归结为哪一个最适合你的项目目标。有时WebForms和丰富的第三方控件供应商的可用性将会更可取，并且在某些情况下，原始的简单性和细粒度的HTML控制将有利于MVC。
为什么不把两者都放在Northwind上，看看哪种方式最适合你和你的情况？
你也可以考虑开发者的背景（如果有的话）。
如果他们来自一个严格的asp.net的背景下，他们将围绕WCSF更舒适的（虽然在我的经验，它仍然把他们几个星期，真正成为各地MVP舒服）。如果他们来自java/rails背景，或者之前使用过其他MVC体系结构，那么显然他们会更开心（并且根据我的经验，除了MVC之外，其他任何事情都会变得非常流行）。
我们在做完全相同的评估后选择了WCSF。我们觉得MVP模式给了我们更多的选择，例如使用服务器控件的能力。我们的开发团队大多由来自多种学科（如C++，Biztalk和Web等）的程序员组成，但他们都专注于MS类型开发，所以采用模式的学习曲线并不像我们的团队那么重要。
我们非常满意我们的选择。
不开始一场火焰战争，但我发现WCSF是相当复杂的。 MVC的优雅和简洁吹走了MVP，这感觉就像是刚刚移植到webforms上的模式。
MVC是一个更简单的模式，更类似于所有其他框架怎么做Web开发。 WebForms仅仅是太多的跳跃和过多的抽象层次来尝试实现简单性。 恕我直言，MVC将在几年内成为默认的ASP.NET架构，因为越来越多的人意识到它带给我们的简单易用的开发和测试。我一直在做MVC开发一年半，甚至不会想到回到一个新项目的WebForms。
一个ASP.NET MVC的网站可能会更容易比同等 WCSF版本进行测试。
这是正确的，因为它采用了新的抽象类 的HttpContext，HttpRequest对象，HttpResponse对象等没有什么本质上 更易测试的莫过于MVP模式MVC模式。 他们都是“分离演示文稿”的实例，并且都增加了可测试性 。
这可能是有争议的，但有文献表明，如果您有视图是逻辑打包的，那么使用MVP设计模型更容易进行单元测试，然后使用MVC设计模型。总而言之，在MVP设计模型中，Presenter正在处理可能由MVC设计模型中的View处理的工作。可能包含在MVC视图中的逻辑不便于单元测试。以下是我已阅读的文献的一些参考资料，其中涵盖了这个概念，以及为什么保持您的View轻量级更好的原因包括促进单元测试等多种原因。
http://martinfowler.com/eaaDev/uiArchs.html
你还满意这个决定吗？似乎WCSF已经被MS逐步淘汰，而MVC越来越受欢迎。谢谢。 – 2014-05-28 15:16:10