我最近对不同类型的模型视图架构进行了一些调查，需要决定将来的内部开发采用哪一种。 由于我目前在一家拥有 ASP.NET 技能的 Microsoft 商店工作，看来我的选择是 ASP.NET MVC 和 WCSF（Monorail 可能不适用，因为 Microsoft 不支持它）。
阅读ASP.NET MVC 框架，以 WCSF 为衡量标准，我总结出以下几点：
- ASP.NET MVC 不能使用依赖回发的 Web 控件，而 WCSF 可以。
- 与 WCSF 站点相比，您可以更好地控制 ASP.NET MVC 站点中的 URL。
- ASP.NET MVC 站点可能比等效的 WCSF 版本更容易测试。
- 似乎 WCSF 在某些情况下仍然使用后台代码来控制 UI 事件，但 ASP.NET MVC 不允许这样做。
还有哪些其他考虑因素？
我误解了什么？
有没有人使用过这两个框架并提供建议？
I have recently been doing a bit of investigation into the different types of Model View architectures, and need to decide which one to pursue for future in-house development. As I'm currently working in a Microsoft shop that has ASP.NET skills, it seems my options are between ASP.NET MVC and WCSF (Monorail is probably out of the as it wouldn't be supported by Microsoft).
After reading the ASP.NET MVC framework, using the WCSF as a yardstick, I picked up the following points:
- ASP.NET MVC cannot use web controls that rely on postbacks, whereas WCSF can.
- You have more control over the urls in an ASP.NET MVC site as opposed to a WCSF site.
- An ASP.NET MVC site will probably be easier to test than an equivalent WCSF version.
- It seems that the WCSF still uses the code behind to control UI events under some circumstances, but ASP.NET MVC doesn't allow this.
What are some of the other considerations?
What have I misunderstood?
Is there anybody out there who has used both frameworks and has advice either way?
发布评论
评论（7）
MVC 是一个更简单的范例，并且更类似于所有其他框架进行 Web 开发的方式。 WebForms 只是太多的跳跃和太多的抽象层来尝试实现简单性。
恕我直言，MVC 将在几年内成为默认的 ASP.NET 架构，因为越来越多的人意识到它给我们带来的开发和测试的简单性和易用性。 我已经从事 MVC 开发一年半了，甚至从来没有想过在新项目中回到 WebForms。
MVC is a much simpler paradigm and is more similar to how all other frameworks do web development. WebForms is simply way too much jumping through hoops and too many layers of abstraction to try and achieve simplicity.
IMHO, MVC will be the default ASP.NET architecture within a few years, as more and more people realize the simplicity and ease of development and testing that it brings with us. I have been doing MVC development for a year and a half and would never even think of going back to WebForms on a new project.
这可能是有争议的，但有文献表明，如果您的视图充满了逻辑，那么使用 MVP 设计模型比 MVC 设计模型更容易进行单元测试。 总而言之，在 MVP 设计模型中，Presenter 处理的工作可能由 MVC 设计模型中的 View 处理。 MVC 视图中可能包含的逻辑不利于单元测试。 以下是我读过的一些参考文献，这些文献涵盖了这个概念，以及为什么保持视图明亮更好的原因有很多，包括促进单元测试。
http://martinfowler.com/eaaDev/uiArchs.html
http://martinfowler.com/eaaDev/SupervisingPresenter.html
http://martinfowler.com/eaaDev/PassiveScreen.html
This is probably debatable, but there is literature to suggest using an MVP design model is easier to unit test then an MVC design model if you have Views that are packed with logic. To summarize, in the MVP design model the Presenter is handling the work that might be handled by the View in the MVC design model. The logic that might be contained in the MVC View does not facilitate unit testing. Here are some references to literature that I have read that would cover this concept and the reasons why keeping your View light is better for many reasons including facilitating unit testing.
http://martinfowler.com/eaaDev/uiArchs.html
http://martinfowler.com/eaaDev/SupervisingPresenter.html
http://martinfowler.com/eaaDev/PassiveScreen.html
为什么不将两者都连接到 Northwind，看看哪一个最适合您和您的情况呢？
Why not attach both to Northwind and see which fits best for you and your situation?
在做了完全相同的评估后，我们选择了 WCSF。 我们认为 MVP 模式给了我们更多的选择，即使用服务器控件的能力。 我们的开发团队主要由来自 C++、Biztalk 和 Web 等众多学科的程序员组成，但他们都主要专注于 MS 类型的开发，因此采用模式的学习曲线对于我们的团队来说并不那么困难。
我们对我们的选择非常满意。
We opted for the WCSF after doing exactly the same evaluation. We felt that the MVP pattern gave us more options i.e Ability to use server controls. Our development team is mostly made up of Programmers from a myriad of disciplines i.e C++, Biztalk and web etc. but had all focused mostly on MS type development, so the learning curve in adopting the patterns was not so much for our team.
We are more than happy with our choice.
您还可以考虑开发人员的背景（如果已经确定）。
如果他们有严格的 ASP.NET 背景，他们会更适应 WCSF（尽管根据我的经验，他们仍然需要几周的时间才能真正适应 MVP）。
如果他们有 java/rails 背景，或者以前使用过其他 MVC 架构，那么显然他们会更高兴（根据我的经验，他们对 MVC 以外的任何事情都非常傲慢）。
You might also consider the background's of your developers (if any have already been identified).
If they come from a strict asp.net background, they will be more comfortable around WCSF (although in my experience, it still took them a few weeks to really be comfortable around MVP).
If they come from a java/rails background, or have used other MVC architectures before, then obviously they'll be happier there (and in my experience get very snooty about anything other than MVC).
并不是要引发口水战，但我发现 WCSF 相当复杂。 MVC 的优雅和简洁击败了 MVP，感觉就像是一种刚刚嫁接到 Web 表单上的模式。
Not to start a flame war but I found the WCSF to be quite convoluted. The elegance and simplicity of MVC blows away MVP which feels like a pattern that is just grafted onto webforms.
您应该将 WCSF 视为有关如何使用现有 WebForms 基础结构的指南，特别是引入模型-视图-呈现器来帮助强制实施关注点分离。 它还提高了生成代码的可测试性。
如果您可以针对 3.5 SP1，则可以将新的路由系统与传统的 WebForms 站点一起使用。 路由不限于MVC。 例如，看一下动态数据（也在 3.5 SP1 中提供）。
这是事实，因为它使用了 HttpContext、HttpRequest、HttpResponse 等新的抽象类。MVC 模式本质上没有什么比 MVP 模式更可测试的了。 它们都是“分离演示”的实例，并且都提高了可测试性。
在Model-View-Presenter中，由于外部世界与视图交互（即URL指向视图），视图自然会响应这些事件。 它们应该尽可能简单，通过调用演示者或提供演示者可以订阅的事件。
模型-视图-控制器通过让外部世界与控制器交互来克服这一限制。 这意味着您对非演示性事物的看法可能会非常“愚蠢”。
至于您应该使用哪一种，我认为答案取决于哪一种最适合您的项目目标。 有时 WebForms 和丰富的第三方控件供应商可用性会更好，而在某些情况下，原始的简单性和细粒度的 HTML 控件将有利于 MVC。
You should think of WCSF as guidance about how to use the existing WebForms infrastructure, especially introducing Model-View-Presenter to help enforce separation of concerns. It also increases the testability of the resulting code.
If you can target 3.5 SP1, you can use the new Routing system with a traditional WebForms site. Routing is not limited to MVC. For example, take a look at Dynamic Data (which also ships in 3.5 SP1).
This is true because it uses the new abstractions classes for HttpContext, HttpRequest, HttpResponse, etc. There's nothing inherently more testable about the MVC pattern than the MVP pattern. They're both instances of "Separated Presentation", and both increase testability.
In Model-View-Presenter, since the outside world interacts with views (i.e., the URL points to the view), the views will naturally be responding to these events. They should be as simple as possible, either by calling the presenter or by offering events that the presenter can subscribe to.
Model-View-Controller overcomes this limitation by having the outside world interact with controllers. This means your views can be a lot "dumber" about non-presentation things.
As for which you should use, I think the answer comes down to which one best suits your project goals. Sometimes WebForms and the rich third party control vendor availability will be preferable, and in some cases, raw simplicity and fine-grained HTML control will favor MVC.