ASP.NET MVP与ASP.NET MVC的区别

Question

我的公司正在努力做出关于如何追求未来发展的明智决策。

我们似乎已经将未来的内部和外部应用程序限制为Web应用程序。但是，从那时起，我们仍然有些困惑。

这里有大量支持SharePoint的人。据我所知，SharePoint基本上是使用MVP的ASP.NET。

其他人想使用新的MVC风格使用普通的ASP.NET。

我还被告知它们不容易很好地协同工作。

看起来SharePoint（和ASP.NET MVP）将会成为胜利者。在我们走向这个方向之前，我想问：

如果我们选择以SharePoint（即ASP.NET和MVP）为基础，在接下来的5-10年中进行开发工作，我们会失去什么？这是一个大问题还是一些“好东西”我们正在失去。

（这必须是一个相当严重的问题，才能让管理层改变方向。）

- Vaccano

---

SharePoint不是ASP.Net MVP，不能与MVC进行比较。根据维基百科的定义，SharePoint是一种基于Web技术的服务器，可用于构建门户、协作站点以及内容管理站点。它在许多功能方面非常灵活，并支持各种企业和Web场景。它也因文档管理解决方案而广受欢迎。 - jgauffin

@Yuriy 是的，Web客户端软件工厂是MS实现MVP的方式。它非常难以使用，而我上一次使用它的经历（大约在.NET 3.0左右，不是指3.5）中，项目甚至根本无法工作，因为尝试绑定标准MVP页面时遇到了大量基本IOC解析失败。这就是我创建自己的MVP框架的原因。 - Chris Marisic

为了弥合关于SharePoint=MVP vs. MVC的问题和关于Webforms vs. MVC的答案之间的差距：SharePoint使用的ASP.NET模型称为Webforms，而不是MVP。 - chiccodoro

自从你做出决定已经一年半了。我猜你选择了Sharepoint路径。有后悔吗？顺便说一句：构建Web应用程序并不是在MVC和Sharepoint之间进行选择，而是在MVC和WebForms+MVP之间进行选择。Sharepoint是一个完全不同的层，主要用于内部网络环境和非常特殊的目的。Sharepoint不是通用的Web应用程序开发平台。如果你这样想，那么你现在一定非常后悔。你的客户也是如此。 - Robert Koritnik

Answer 1

无论发生什么，WebForms 在某个时刻都会变成一个又臭又长的混乱代码。如果您必须使用 WebForms，请不要使用 PostBack 和 Page LifeCycle 模型 - 使用 ASPX 页面和 Presenter 处理 Get 请求，并针对每个 Post 请求使用 Handler 或空白 ASPX 页面。这样做会让您的代码更像 MVC。

- mcintyre321

Answer 2

我认为你的选择在很大程度上取决于你的开发人员是谁以及你打算构建哪种应用程序。

如果您构建大量使用第三方（或自己的）自定义控件的crud样式应用程序，则保持Webforms可能是一个不错的选择。

如果您构建具有大量客户端功能的"web"样式应用程序，则MVC是更好的选择。

如果您主要拥有新手开发人员，则Webforms可能更好。 如果您拥有更有经验的开发人员，即使他们对asp.net不熟悉，MVC也可能是更好的选择。

如果您正在构建非常数据为中心的应用程序并存在复杂的互联关系，则MVC可能是更好的选择。

有许多原因可以选择其中之一，它总是“取决于...”。

此外，MVC和Webforms并不完全不兼容。 您无法在同一页中使用它们，但可以在同一站点中同时使用两者。 而且，如上面的评论所说，Sharepoint并非Webforms或MVP本身。 它是基于Webforms的一种自己的东西。 它非常“Webpart”导向，这只是一种表示您构建了许多自定义控件的方式。

- Erik Funkenbusch

---

说实话，通过一些项目文件的修改，我90%确定你可以同时运行WebForms和MVC，如果你真的想这么做的话。 - Chris Marisic

@ChrisMarisic：我个人能够将MVC集成到Sharepoint中，在某些项目中，这使我能够以现代化和更好的方式为客户开发高度定制的UI。 - Robert Koritnik

Answer 3

我一直坚定地主张将关注点分离（SOC）建入软件中，无论您使用MVVM、MVC还是MVP，这三种模式都非常不错。针对ASP.NET而言，我认为您应该使用MVC3。

我已经是一名.NET开发人员多年了，并编写了基于StructureMap的MVP模式（我的博客上有很多相关内容），有一段时间我并没有看到从离开WebForms转向MVC所带来的好处。然而，在与ASP.NET打交道这么长时间后，我已经受够了完全超出我的控制范围的ASP.NET WebForms错误。

WebForms的主要错误是ViewState超时导致通用加密异常，第二个错误是ViewState被客户端或某些提交截断，导致合法的加密错误。使用MVC就不再适用这些错误了。在.NET4中，我尝试创建一个没有ViewState的WebForms应用程序，使用.NET4中添加的新功能，但完全没有效果，这巩固了我放弃WebForms的决定。

在MVC、MVC2和MVC3中，MVC3和Razor视图引擎提供的功能集最为强大。您可以获得MVC2的所有增强功能，以及Razor视图引擎让您创建的更加清晰的视图。此外，您还可以获得全局操作筛选器和内置的jQuery客户端模板（我90%确定）。

我也会像使用MVVM一样接近MVC，其中我将有三个不同的实体集：我的视图模型、我的域实体和我的物理数据库模型。（最后一个集合可能是域实体，也可能不是。我已经开始意识到，尝试让您的纯域实体与您的数据库层配合工作可能在高级阶段不太理想。）

- Chris Marisic

---

尝试使用Spark视图引擎，让视图呈现得更加完美。 - jgauffin

我宁愿使用Razor并获得完整的语法高亮/智能感知。 - Chris Marisic

尝试安装可用于vstudio2010的语法高亮/智能感知插件了吗？ - jgauffin

以前不知道有这个存在，那可能有意义，但是有了 Razor，我为什么要使用 Spark 呢？ - Chris Marisic

对于你最后一段的观察：通常最好拥有一个包含所有实体的应用程序/领域模型，以及一个数据模型，该数据模型具有其自己的一些模型（很多时候是从领域模型继承而来，因为它们具有更多的字段），但视图模型实体通常只有领域模型的子集，因为它们很少使用不同的数据。主要的是，领域模型是完整的模型，其他两个模型通常与之相关。 - Robert Koritnik

Answer 4

如果你正在执行页面后退以处理事件，我建议使用MVP，因为Presenter将包含所有版本视图（不同的用户界面，如网页、iPhone、Android、Windows表单）的事件处理程序，并具有统一的行为。换句话说，你不需要为每个视图在代码后台编写控件事件。至少，它们只需调用Presenter的事件处理程序方法或引发Presenter处理的事件即可。

如果你正在创建Web应用程序并且大量使用Ajax进行页面更新，具有一个或多个Web视图和跨浏览器JavaScript库（如jQuery），我建议使用MVC。

因此，这取决于你想如何处理页面事件。MVP和MVC都有关注点分离。MVP更加基于服务器，更容易添加多个UI，而MVC更加基于客户端，用于事件处理和更加Web中心化。

- Antony Booth

Answer 5

从我的经验来看，对于数据中心复杂的LOB应用程序，强制执行MVP模式要好得多。

MVP提供了更大的分离，因为您的Presenter没有Web中心概念的知识。 代码覆盖率也增加了，因为视图中没有条件代码。 我们有几个应用程序，其中Presenter在Web和Windows应用程序之间使用。 您的Presenter引用了视图的完整抽象，而asp.net MVC依赖于视图相关对象的抽象（HttpContextBase等）

尽管如此，您需要将其设计到Web表单中，这不是开箱即用的，但如果您第一次正确地设计并且有理解它并坚持它的开发人员，您最终会得到一个非常干净的解决方案。

有一些可靠的框架可以支持WebForms中的MVP：

http://www.codeguru.com/csharp/.net/net_general/patterns/article.php/c15173

同时也可以访问webformsmvp点com网站。

- En55