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

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

您应该将wcsf看作是关于如何使用现有WebForms基础结构的指导,特别是引入模型视图演示器来帮助实现关注点分离。它还增加了结果代码的可测试性。

与WCSF站点相比,您对ASP.NET MVC站点中的URL有更多的控制。

如果您可以以3.5SP1为目标,则可以将新的路由系统与传统的WebForms站点结合使用。路由不限于MVC。例如,查看动态数据(也在3.5sp1中提供)。

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

这是真的,因为它为httpContext、httpRequest、httpResponse等使用了新的抽象类。对于MVC模式,没有什么比MVP模式更具有内在的可测试性。它们都是“分离表示”的实例,并且都增加了可测试性。

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

在模型视图演示者中,由于外部世界与视图交互(即,URL指向视图),因此视图将自然地响应这些事件。它们应该尽可能简单,通过调用演示者或提供演示者可以订阅的事件。

模型视图控制器通过让外部世界与控制器交互来克服这一限制。这意味着你的观点对于非展示性的东西可能会非常“愚蠢”。

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

不是要发动一场圣火战争,但我发现世界科学基金会非常复杂。MVC的优雅和简单将MVP吹走,MVP感觉就像是一个刚移植到网络表单上的模式。

在做了完全相同的评估之后,我们选择了wcsf。我们觉得MVP模式给了我们更多的选择,即使用服务器控制的能力。我们的开发团队主要是由众多学科的程序员组成的,如C++、BizTalk和WEB等,但大部分都集中在MS类型开发上,所以采用模式的学习曲线对我们的团队来说不是那么多。

我们对自己的选择非常满意。

您还可以考虑开发人员的背景(如果已经确定了任何背景)。

如果他们来自一个严格的ASP.NET背景,他们将在wcsf周围更舒适(尽管在我的经验中,他们仍然花了几个星期才真正在MVP周围感到舒适)。

如果它们来自Java/Rails背景,或者以前使用过其他MVC体系结构,那么显然它们会更快乐(在我的经验中,除了MVC以外,其他任何东西都非常傲慢)。

MVC是一个简单得多的范例,并且更类似于所有其他框架如何进行Web开发。WebForms简单地说是太多的跳跃,太多的抽象层试图实现简单。 随着越来越多的人认识到MVC带来的开发和测试的简单性和易用性,MVC将在几年内成为默认的ASP.NET体系结构。我已经做了一年半的MVC开发工作,我甚至都不想回到一个新项目的webforms。

一个ASP.NET MVC站点可能比同等站点更容易测试 WCSF版本。

这是真的,因为它使用新的抽象类 httpContext、httpRequest、httpResponse等。没有 与MVP模式相比,MVC模式固有的可测试性更强。 它们都是“单独呈现”的例子,而且都会增加 可测试性。

这可能是有争议的,但有文献建议使用MVP设计模型更容易进行单元测试,如果您有打包了逻辑的视图,则使用MVC设计模型更容易。总而言之,在MVP设计模型中,演示者正在处理MVC设计模型中视图可能处理的工作。MVC视图中可能包含的逻辑不便于单元测试。以下是一些参考文献,我已经阅读过,这些文献将涵盖这个概念,以及为什么保持您的观点更好,原因有很多,包括促进单元测试。

http://martinfowler.com/eaaDev/uiArchs.html

http://martinfowler.com/eaaDev/SupervisingPresenter.html

http://martinfowler.com/eaaDev/PassiveScreen.html

为什么不把两者都附在北风上,看看哪一个最适合你和你的情况?