我最近对不同类型的模型视图架构进行了一些调查，需要决定在未来的内部开发中采用哪种架构。由于我目前在一家拥有ASP.NET技能的微软商店工作，似乎我的选择是在ASP.NET MVC和WCSF之间（单轨可能不在微软的支持下）。
阅读the ASP.NET MVC framework, using the WCSF as a yardstick后，我提到了以下几点：
还有哪些其他考虑因素？
我误解了什么？
是否有人使用这两种框架并提出建议？
答案 0 :(得分：15)
ASP.NET MVC不能使用依赖回发的Web控件，而WCSF可以。
您应该将WCSF视为有关如何使用现有WebForms基础结构的指导，尤其是引入Model-View-Presenter以帮助强制执行关注点分离。它还增加了生成代码的可测试性。
您可以更好地控制ASP.NET MVC站点中的URL而不是WCSF站点。
如果您可以定位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指向视图），因此视图自然会响应这些事件。它们应该尽可能简单，通过调用演示者或提供演示者可以订阅的事件。
模型 - 视图 - 控制器通过让外部世界与控制器交互来克服这一限制。这意味着你的观点对于非演示事物来说可能很多“笨拙”。
至于你应该使用哪一个，我认为答案归结为哪一个最适合你的项目目标。有时WebForms和富有的第三方控制供应商可用性会更好，在某些情况下，原始的简单性和细粒度的HTML控件将有利于MVC。
答案 1 :(得分：6)
不发动火焰战，但我发现WCSF非常复杂。 MVC的优雅和简洁将MVP吹走，感觉就像一个刚刚被嫁接到网页上的图案。
答案 2 :(得分：2)
我们在完成相同的评估后选择了WCSF。我们认为MVP模式为我们提供了更多选择，即能够使用服务器控件。我们的开发团队主要由来自无数学科的程序员组成，即C ++，Biztalk和Web等，但主要都集中在MS类型开发上，因此采用模式的学习曲线对我们的团队来说并不是那么多。
我们非常满意我们的选择。
答案 3 :(得分：1)
您也可以考虑开发人员的背景（如果已经确定了）。
如果他们来自严格的asp.net背景，那么他们会更加适应WCSF（尽管根据我的经验，他们还需要几周时间才能真正适应MVP）。
如果他们来自java / rails背景，或者以前使用过其他MVC架构，那么显然他们会更高兴（根据我的经验，除了MVC之外的其他任何事情都会非常傲慢）。
答案 4 :(得分：1)
MVC是一个更简单的范例，更类似于所有其他框架进行Web开发的方式。 WebForms简单地过多地跳过了箍和太多的抽象层来试图实现简单性。 恕我直言，MVC将在几年内成为默认的ASP.NET架构，因为越来越多的人意识到它带来的简单易用的开发和测试。我已经做了一年半的MVC开发，甚至从未想过要在一个新项目上回到WebForms。
答案 5 :(得分：1)
ASP.NET MVC站点可能比同等版本更容易测试 WCSF版本。
这是真的，因为它使用了新的抽象类 HttpContext，HttpRequest，HttpResponse等等什么都没有 关于MVC模式本质上比MVP模式更可测试。 它们都是“分离演示”的实例，并且都增加了 可测试性。
这可能是值得商榷的，但是有文献建议使用MVP设计模型更容易进行单元测试，然后是MVC设计模型，如果你有充满逻辑的视图。总而言之，在MVP设计模型中，Presenter正在处理可能由MVC设计模型中的View处理的工作。可能包含在MVC视图中的逻辑不利于单元测试。以下是我读过的一些文献参考资料，这些文献将涵盖这个概念，以及为什么保持你的View灯更好的原因有很多，包括促进单元测试。
http://martinfowler.com/eaaDev/uiArchs.html
答案 6 :(得分：0)
为什么不将两者都附加到Northwind并查看哪种最适合您和您的情况？