ASP.NET MVP 与 ASP.NET MVC
我的公司正在努力就如何追求未来发展做出明智的决定。
我们似乎已经将未来的内部和外部应用程序缩小为 Web 应用程序。但从那时起我们仍然有点困惑。
这里有大量对 Sharepoint 的支持。据我了解，Sharepoint 基本上是使用 MVP 的 ASP.NET。
其他人希望使用较新的 MVC 风格来使用普通的 ASP.NET。
我还被告知，这些并不能轻易地协同工作。
看起来 Sharepoint（和 ASP.NET MVP）将成为赢家。在我们朝这个方向前进之前，我想问：
如果我们选择将未来 5-10 年的开发工作基于 Sharepoint（即 ASP.NET 和 MVP），我们会放弃什么？我们失去的是一件大事还是只是一些“美好的东西”？
（现在让管理层改变方向肯定是一件相当大的事情。）
My company is trying to make an informed decision about how to pursue future development.
We seem to have narrowed down our future internal and external Applications to being web applications. But we are still a bit confused from that point.
There is a large amount of support for Sharepoint here. As I understand it, Sharepoint is basically ASP.NET using MVP.
Others want to use normal ASP.NET using the newer MVC style.
I am also told that these don't easily play well together.
It is looking like Sharepoint (and ASP.NET MVP) is going to be the winner. Before we go that direction, I wanted to ask:
If we choose to base the next 5-10 years of our development efforts off of Sharepoint (ie ASP.NET and MVP) what are we giving up? And is it a big deal or just some "nice to haves" that we are loosing.
(It would have to be a fairly big deal to get management to change direction now.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
无论发生什么，WebForms 在某些时候都会变成一团糟。如果您必须使用 Web 表单，请不要使用回发和页面 lifycycle 模型 - 拥有带有演示器的 aspx 页面用于获取请求，并且每个帖子都有一个处理程序或空 aspx。这样感觉会更像 MVC
Whatever happens, WebForms will turn into a big ugly mess at some point. If you have to use webforms, don't use the postback and page lifycycle model - have aspx pages with presenters for get requests, and have a handler or empty aspx per post. It'll feel a lot more like MVC that way
我想说，你的选择在很大程度上取决于你的开发人员是谁，以及你打算构建什么样的应用程序。
如果您构建的应用程序主要类似于原始数据，并且大量使用第三方（或您自己的）自定义控件，那么继续使用 Webforms 可能是一个好主意。
如果您主要构建具有大量客户端功能的“Web”样式应用程序，那么 MVC 是更好的选择。
如果您的开发人员大多是新手，那么 Webforms 可能会更好。如果您有经验丰富的开发人员，即使他们是 ASP.NET 新手，那么 MVC 可能是更好的选择。
如果您正在构建具有复杂互连的以数据为中心的应用程序，那么 MVC 可能是更好的选择。
您选择其中之一的原因有很多，而且总是“这取决于……”。
此外，MVC 和 Webforms 也并非完全不兼容。您不能在同一页面中使用它们，但可以在同一站点中使用它们。另外，就像上面的评论所说，Sharepoint 本身并不是 Webforms 或 MVP。它是一种基于 Webforms 的自己的东西。它非常面向“Webpart”，这只是您构建大量自定义控件的一种方式。
I would say that what you choose depends heavily upon who your developers are, and what kind of apps you intend to build.
If you build largely crud-like apps that make a lot of use of third party (or your own) custom controls, then staying with Webforms is probably a good idea.
If you build largely "web" style apps with lots of client-side functionality, then MVC is a much better choice.
If you have largely newbie developers, Webforms may be better. If you have more experienced developers, even if they're new to asp.net then MVC may be a better choice.
If you are building very data-centric applications with complex interconnections, then MVC may be a better choice.
There are lots of reasons why you might choose one or the other, and it's always "it depends on...".
Also, MVC and Webforms are not completely incompatible. You can't use them in the same page, but you can use both in the same site. Also, like the comment above says, Sharepoint is not Webforms or MVP per se.. it's kind of it's own thing that is based on webforms. It's very "Webpart" oriented, which is just a way of saying you build lots of custom controls.
我一直强烈支持将关注点分离 (SOC) 内置到软件中，无论您使用 MVVM、MVC 还是 MVP，这三种模式都非常好。由于这完全特定于 ASP.NET，我想说您应该使用 MVC3。
我已经成为 .NET 开发人员多年，并编写了基于 StructureMap 构建的 MVP 模式（我的博客上有很多关于它的内容），有一段时间我从未见过处理从将 Web 表单保留到 Web 表单相关的更改的好处。转到 MVC。然而，在与 ASP.NET 打交道这么长时间之后，我刚刚遇到了完全超出我控制范围的 ASP.NET Webforms 错误。
Web 表单中的主要错误是 ViewState 超时导致通用加密异常，第二个错误是 ViewState 被客户端截断或以某种方式发布，从而导致合法的加密错误。对于 MVC，这些错误不再适用。在 .NET4 中，我尝试使用他们在 .NET4 中添加的新功能创建一个没有 ViewState 的 Webforms 应用程序，但这完全不起作用，这更加坚定了 Webforms 时代已经过去的决定。
在 MVC、MVC2 和 MVC3 中，MVC3 和 Razor 视图引擎附带的功能集是最强大的。您可以获得 MVC2 附带的所有增强功能以及 Razor 视图引擎允许您创建的更清晰的视图，最重要的是您可以获得全局操作过滤器和烘焙的 jQuery 客户端模板（我 90% 确定）。
我还将采用与 MVVM 非常相似的方式来处理 MVC，其中我将拥有 3 组不同的实体：我的视图模型、我的域实体和我的物理数据库模型。 （最后一组可能是也可能不是域实体，我已经开始意识到尝试让纯域实体与数据库层一起工作在高级阶段可能不是最佳的）
I have been a strong proponent of Separation of Concern (SOC) being built into software whether you use MVVM, MVC or MVP all three patterns are quite nice. With this being completely specific to ASP.NET, I would state you should use MVC3.
I have been a .NET developer for years now and have written my MVP pattern that is built on top of StructureMap (lots on my blog about it) and for a while I never saw the benefit of dealing with the changes associated from leaving webforms to goto MVC. However after dealing with ASP.NET for so long I've just had it with ASP.NET webforms errors that are completely out of my control.
The main errors from webforms occur with the ViewState timing out resulting in the generic cryptographic exception and the 2nd is where the ViewState is just truncated by the client or post somehow resulting in legitimate cryptographic errors. With MVC these errors just aren't applicable anymore. With .NET4 I attempted to create a webforms application without ViewState with the new features they added in .NET4 and that completely didn't work which cemented by decision that webforms time is past.
Out of MVC, MVC2 and MVC3 the feature set that comes with the MVC3 and the Razor view-engine is the most robust. You get all of the enhancements that came with MVC2 along with the much cleaner Views that the Razor view engine lets you create, on top of that you get global action filters and the baked jQuery client side templating (I'm 90% sure).
I would also approach MVC very similarly to MVVM where I would have 3 distinct sets of entities, my view models, my domain entities and my physical database models. (The last set may, or may not be the domain entities, I've started to realize trying to make your pure domain entities work with your database layer can be suboptimal at advanced stages)
如果您要执行页面回发来处理事件，我建议使用 MVP，因为 Presenter 将包含所有版本视图（不同的用户界面，如网页、iPhone、Android、Windows 表单）的事件处理程序，并具有统一的行为。换句话说，您不需要在每个视图的代码隐藏中编写控制事件。至少，他们只会调用 Presenter 的事件处理程序方法或引发 Presenter 处理的事件。
如果您正在创建 Web 应用程序并大量使用 Ajax 进行页面更新，并使用一个或多个 Web 视图和跨浏览器 JavaScript 库（例如 jQuery），我会推荐 MVC。
因此，这取决于您希望如何处理页面事件。 MVP 和MVC 都有关注点分离。 MVP 更基于服务器，更容易添加多个 UI，而 MVC 更基于客户端，用于事件处理并且更以 Web 为中心。
If you are performing page post-backs to handle events, I would suggest MVP as the Presenter would contain the event handlers for all versions of the view (Different user interfaces such as web pages, iPhone, Android, Windows forms), with a uniform behavior. In other words, you would not need to write control events in a code-behind for every view. At least, they'd do nothing more than call the Presenter's event handler method or raise an event the Presenter handles.
If you are creating web applications and heavily using Ajax for page updates, with one or more web views and a cross-browser JavaScript library, such as jQuery, I would recommend MVC.
So it comes down to how you want to handle page events. MVP & MVC both have separation of concerns. MVP is more server based and easier to add multiple UI's and MVC is more client based, for event handling and more web centric.
根据我的经验，强烈执行的 MVP 模式对于以数据为中心的复杂 LOB 应用程序来说要好得多。
MVP 提供了更大的分离性，因为您的演示者不了解以网络为中心的概念。
由于视图中没有条件代码，代码覆盖率也会增加。
我们有几个应用程序在 Web 和 Windows 应用程序之间使用演示者。
您的演示者指的是视图的完整抽象，asp.net MVC 依赖于视图依赖项的抽象（HttpContextBase 等）。
这一切都表明您需要将其设计到 Web 表单中，它不是开箱即用的，但如果您这样做第一次就做对，并且让开发人员理解它并坚持下去，你最终会得到一个非常干净的解决方案。
有一些可靠的框架可以支持 Web 表单中的 MVP：
http ://www.codeguru.com/csharp/.net/net_general/patterns/article.php/c15173
webformsmvp .com 也是如此。
From my experience, a strongly enforced MVP pattern has been much better for data centric complex LOB applications.
MVP offers greater seperation as your presenters have no knowledge of web centric concepts.
Code coverage is also increased as you have no conditional code in the views.
We have several apps that where the presenter is used between both web and windows apps.
You presenter referes to a complete abstraction of the view, asp.net MVC relies on abstractions of view dependants (HttpContextBase etc.)
That all said you need to design this into web forms, its not out of the box, but if you do it right first time and have developers that understand it and stick to it you end up with a very clean solution.
there are some solid frameworks out there to support MVP in webforms:
http://www.codeguru.com/csharp/.net/net_general/patterns/article.php/c15173
webformsmvp dot com as well.