ASP.NET MVC与Web客户端软件工厂(WCSF)

我最近对不同类型的模型视图架构进行了一些调查,需要决定在未来的内部开发中采用哪种架构.由于我目前在一家拥有ASP.NET技能的微软商店工作,似乎我的选择是在ASP.NET MVC和WCSF之间(单轨可能不在微软的支持下).

在阅读ASP.NET MVC框架后,使用WCSF作为衡量标准,我选择了以下几点:

ASP.NET MVC不能使用依赖回发的Web控件,而WCSF可以.

您可以更好地控制ASP.NET MVC站点中的URL,而不是WCSF站点.

与同等的WCSF版本相比,ASP.NET MVC站点可能更容易测试.

在某些情况下,似乎WCSF仍然使用后面的代码来控制UI事件,但是ASP.NET MVC不允许这样做.

还有哪些其他考虑因素？
我误解了什么？
有没有人使用这两个框架并提出建议？

ASP.NET MVC不能使用依赖回发的Web控件,而WCSF可以.

您应该将WCSF视为有关如何使用现有WebForms基础结构的指导,尤其是引入Model-View-Presenter以帮助强制执行关注点分离.它还增加了结果代码的可测试性.

您可以更好地控制ASP.NET MVC站点中的URL,而不是WCSF站点.

如果您可以定位3.5 SP1,则可以将新路由系统与传统WebForms站点一起使用.路由不仅限于MVC.例如,看看动态数据(也在3.5 SP1中提供).

与同等的WCSF版本相比,ASP.NET MVC站点可能更容易测试.

这是正确的,因为它使用了新的抽象类,用于HttpContext,HttpRequest,HttpResponse等.对于MVC模式而言,没有什么比MVP模式更可测试.它们都是"分离演示"的实例,都增加了可测试性.

在某些情况下,似乎WCSF仍然使用后面的代码来控制UI事件,但ASP.NET不允许这样做.

在Model-View-Presenter中,由于外部世界与视图交互(即,URL指向视图),视图自然会响应这些事件.它们应该尽可能简单,通过调用演示者或提供演示者可以订阅的事件.

模型 - 视图 - 控制器通过让外部世界与控制器交互来克服这一限制.这意味着你的观点对于非呈现的东西可能是很多"笨拙".

至于你应该使用哪一个,我认为答案归结为哪一个最适合你的项目目标.有时WebForms和富有的第三方控制供应商可用性将是更可取的,在某些情况下,原始的简单性和细粒度的HTML控件将有利于MVC.

不要开始火焰战,但我发现WCSF非常复杂.MVC的优雅和简洁将MVP吹走,感觉就像一个刚刚被嫁接到网页上的图案.