ASP.NET MVP是ASP.NET Webforms和ASP.NET MVC的共生体

Question

我已经用ASP.NET Webforms开发Web应用程序几年了，仍然喜欢它，主要是因为它提供的RAD功能。自两年前以来，ASP.NET MVC作为经典ASP.NET的直接竞争对手现已上市。但我不想放弃所有的Webforms经验并转移到ASP.NET MVC，其中一个原因是我也涉及桌面应用程序开发，而ASP.NET Webforms更类似于它。

现在我发现有第三种ASP.NET开发方法：ASP.NET MVP： http://webformsmvp.com/ 有没有人已经使用过这种ASP.NET的第三种类型？

这是微软的官方方法吗？微软是否支持它？

值得花更多时间去研究吗？

它是两个ASP.NET“世界”的一个有前途的结合吗？

- uhu

Answer 1

这显然是一个主观的意见，它取决于你要解决的特定问题。如果你有一个简单的应用程序，不需要大量的持续维护，并且重要的是展示快速结果，那么我认为出于你提到的原因 - 利用团队技能和RAD，使用MVP是有意义的。

但对于任何更复杂的情况，我认为这不是一个好主意。正如你所提到的，MVP类似于桌面GUI模型；而ASP.NET MVC则设计用于Web的请求-响应性质。特别是随着EditorFor和DisplayFor的引入，视图架构被优化为用作从模型中提取数据的模板。

从可测试性的角度来看，MVC在允许您对小组件进行单元测试方面做得非常好。我认为，由于视图和Presenter之间的耦合更紧密，使用MVP会失去很多这些好处。实际上，MVC采用了“谦逊对话”模式的概念，旨在最小化UI代码，因为它本质上是不可测试的。(ASP.NET) MVC还拥抱Web，生成干净的HTML，旨在通过CSS样式和JavaScript（jQuery）进行增强。我认为MVP鼓励您将视图视为“小部件”的画布，这似乎总是会产生您必须与之斗争的标记。

最后，我认为每当您使用旨在支持一种方法（MVC）并略微修改它（MVP）的平台时，您最终会逆流而上。您无法利用围绕主流方法自然建立的建议、文章和技术开发。例如，个人而言，我宁愿在MVC中使用替代的视图引擎，而不是WebForms引擎。但我没有采取这种做法，因为它是非标准的。有时，“标准”胜过更好。

- Rob