blocks|key|3198449|text|根据WPF的MVVM中包含的文档(一般介绍的第2页)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3198450|这个模式的起源是模糊的，但它可能来自Smalltalk+ApplicationModel模式，就像Martin+Fowler描述的PresentationModel模式一样。Expression团队在开发Blend的版本1时对其进行了调整，以供WPF使用。没有特定于WPF的方面，模型-视图-视图模型模式与PresentationModel是相同的。|3198451|3198452|访问Martin's+Fowler的网站，在Presentation+Model上查找，我们有以下内容|offset|length|3198453|3198454|与被动视图和监督控制器相比，表示模型允许您编写完全独立于用于显示的视图的逻辑。您也不需要依赖视图来存储状态。缺点是您需要在表示模型和视图之间建立一种同步机制。这种同步可能非常简单，但它是必需的。分离的表示需要的同步要少得多，而被动视图根本不需要同步。|blockquote|3198455|3198456|3198457|对于我自己的金属切割CAD-CAM应用程序，我使用Passive+View。其原因是|3198458|3198459|通过让模拟对象实现视图来简化测试，从而允许自动测试我的软件的绝大多数功能|ordered-list-item|3198460|不仅可以重用核心模型，还可以为相关类型的金属切削软件重用不同的视图。|3198461|清楚地记录视图和模型之间的交互。|3198462|销毁对图形用户界面工具包的任何依赖，因为该软件自1985年以来一直在持续开发，并且在底层工具、API甚至语言本身方面发生了几个重大变化。|3198463|<代码>G215|3198464|前三个问题可以通过MVVM、Presentation+Model、Supervising模式来处理。但只有被动视图处理了#4。|3198465|正如Martin+Fowler所说，只有被动视图不需要任何同步方法。MVVM是WPF表示模型的一种实现。您依赖于XAML接口将视图模型中的视图状态与视图本身联系起来。因此，如果以后您更改了UI或它的API，那么您的视图模型也将更改。|3198466|相比之下，被动视图只要求新的UI元素实现View接口。它们实际连接到什么并不重要，因为实现的窗体或控件也会正确响应。|3198467|但代价是在实现视图的新元素时需要额外的一步。您必须决定如何将它们呈现给演示者，以及在哪个抽象级别上。对于某些项目或某些类型的UI+(如对话框)，它已经足够了。|3198468|关于MVVM是WPF的方式的问题，简短的回答是不是它不是。它是一个需要根据围绕应用程序开发的其他问题来考虑的工具。|3198469|entityMap|0|LINK|mutability|MUTABLE|url|http://www.martinfowler.com/eaaDev/PresentationModel.html|1|http://www.martinfowler.com/eaaDev/PassiveScreen.html^0|0|0|0|M|I|0|0|0|0|0|0|P|C|1|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1N|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|1P|8|@]|9|@$G|1Q|H|1R|1|1S]]|A|$]]|$1|I|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1X|8|@]|9|@$G|1Y|H|1Z|1|20]]|A|$]]|$1|Q|3|-4|5|6|7|21|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|22|8|@]|9|@]|A|$]]|$1|U|3|V|5|T|7|23|8|@]|9|@]|A|$]]|$1|W|3|X|5|T|7|24|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|T|7|25|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|26|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|27|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|28|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|29|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|2A|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]]|1D|$1E|$5|1F|1G|1H|A|$1I|1J]]|1K|$5|1F|1G|1H|A|$1I|1L]]]]

According to the included documentation in MVVM for WPF (page 2 of the general introduction) 

<blockquote>
 The origins of this pattern are
 obscure, but it probably derives from
 the Smalltalk ApplicationModel
 pattern, as does the PresentationModel
 pattern described by Martin Fowler. It
 was adapted for WPF use by the
 Expression team as they developed
 version 1 of Blend. Without the
 WPF-specific aspects, the
 Model-View-ViewModel pattern is
 identical with PresentationModel.
</blockquote>

Going to Martin's Fowler's website and looking up <a href="http://www.martinfowler.com/eaaDev/PresentationModel.html">Presentation Model</a> we have this

<blockquote>
 Compared to Passive View and
 Supervising Controller, Presentation
 Model allows you to write logic that
 is completely independent of the views
 used for display. You also do not need
 to rely on the view to store state.
 The downside is that you need a
 synchronization mechanism between the
 presentation model and the view. This
 synchronization can be very simple,
 but it is required. Separated
 Presentation requires much less
 synchronization and Passive View
 doesn't need any at all.
</blockquote>

For my own metal cutting CAD-CAM application I use <a href="http://www.martinfowler.com/eaaDev/PassiveScreen.html">Passive View</a>. The reasons for this are

<ol>
<li>To making testing easier by having mock objects implementing the view thus allow the vast majority of my software's functionality to be automatically tested</li>
<li>To reuse not only the core model but the different views for related types of metal cutting software.</li>
<li>To clearly document the interaction between the views and the model.</li>
<li>To destroy any dependency on the GUI
toolkit as this software has been
continuous development since 1985
and seen several major changes in
the underlying tools, APIs, and even
the language itself.</li>
</ol>

The the concerns of first three can be handled by the MVVM, Presentation Model, Supervising Controller pattern. But only the Passive View addressed #4.

As stated by Martin Fowler only the Passive View doesn't require any synchronization method. MVVM is a implementation of Presentation Model for WPF. You are dependent on the XAML interface to tie the view state located in the View Model with the View itself. So if at a later time you change the UI or it's APIs then your View Model will be changed as well.

In contrast Passive View only requires that the new UI elements implement the View Interface. It doesn't matter what they are actually connected to also as the form or controls implementing responds correctly.

But the price is that you have an extra step when implementing new elements of a view. You have to decide how they are to be presented to the presenter and at what level of abstraction. It is enough that it over kill on some projects or for some types of UI like dialog boxes. 

The short answer to your question about MVVM being THE way for WPF, the answer is no it is not. It is a tool that need to be considered in light of the other issues surrounding the development of your application.

blocks|key|2985178|text|@RS+Conley的答案是对这个主题进行了非常广泛的探讨，我同意大多数人的看法。我认为唯一不同的是底线。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2985179|WPF是中95%25的应用程序的架构。|offset|length|style|BOLD|2985180|选择任何其他架构都意味着满足于一些你所能得到的最好的东西。在RS+Conley的情况下，被动视图可能是最好的方式，但这是远离的正常情况。|2985181|为了理解MVVM是如何变得更好的，让我们看看他在使用PassiveView方法时会失去什么。|2985182|Maintainability|2985183|在被动视图中，ViewModel知道IView，这意味着不保留SRP+(单一责任原则)。PassiveView中的控制器直接与模型和视图交互，因此做的是两件完全不同的事情！|2985184|在虚拟机中，作为应用程序核心的ViewModel只有一个关注点，那就是包含应用程序的状态和逻辑。这类代码的可维护性确实优于PassiveView、MVP或MVC。|2985185|当涉及到自动化测试覆盖时，PassiveView确实更好，但是，代码的良好可维护性要重要得多。可测试性帮助您确保不会破坏代码，而可维护性帮助您从一开始就不会构建有问题的代码。|2985186|当涉及到可维护性时，MVVM和PresentationModel是对以前UI架构的改进，这是因为SRP原则被严格遵守。用MVVM编写足够的代码，你就会明白我的意思了。|2985187|可混合性|2985188|MVVM真正强大的另一个特性是可混合性。由于所有应用程序状态都保存在ViewModel中，因此很容易在设计时伪造数据，从而极大地提高了生产率。这是不可能在PassiveView、MVP或MVC中创建的，因为在所有这些架构中，控制器必须主动地将数据放在视图中。在MVVM中，数据只是“跳转”到视图中，因此可以被模拟。|2985189|可测试性|2985190|这确实是PassiveView优于MVVM的地方。如果UI的100%25单元测试复盖率对你来说至关重要，那么它就是一件大事。然而，在大多数情况下，MVVM允许的覆盖范围已经足够了，您通常会使用常规UI测试添加另一层测试(您最终也会在PassiveView中进行测试)。|2985191|我认为可测试性是这三个特性中不太重要的一个。按重要性排序，它是可维护性、可混合性和可测试性。|2985192|MVVM在哪里不是正确的选择？|2985193|去年我参与了大约15个WPF和Silverlight项目，所有这些项目都非常适合MVVM。我认为在表示逻辑非常庞大的地方，比如在游戏中，MVVM可能不是正确的选择。除了游戏，除了RS+Conley提到的特殊情况外，我真的想不出有什么应用程序类别不适合MVVM。|2985194|entityMap^0|0|4|D|0|1O|2|0|0|0|F|0|0|0|0|0|0|4|0|0|0|4|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1C|8|@$D|1D|E|1E|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1F|8|@$D|1G|E|1H|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1I|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1J|8|@$D|1K|E|1L|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1M|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1N|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1O|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1P|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1T|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1U|8|@$D|1V|E|1W|F|G]]|9|@]|A|$]]|$1|11|3|12|5|6|7|1X|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|20|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|21|8|@]|9|@]|A|$]]]|1A|$]]

@RS Conley's answer is giving a very broad into to the subject, and I agree with most. The only thing I think differently is in the bottom line.

MVVM is THE architecture for 95% of applications in WPF.

Choosing any other architectures is means settling for something that is less than the best you can get. In RS Conley's situation Passive View might be the best way to go, but that is far from being the normal case.

As a way to understand how MVVM is better, let's see what's he's losing when he's going the PassiveView approach.

Maintainability

In Passive View, the ViewModel knows about the IView, which means that SRP (Single Responsibility Principle) is not kept. The Controller in PassiveView interacts directly with both the Model and the View, and therefor is doing two completely different things!.

Under MVVM, the ViewModel, which is the heart of the application only have one concern, which is to contain the state&amp;logic of the application. The Maintainability of such code is really superior to PassiveView, MVP or MVC treamendously.

It is true that PassiveView is better when it comes to Automated Tests Coverege, but IMHO, good maintainability of code is far more important.
Testability helps u make sure you don't break your code, while Maintainability helps you not to build problematic code to begin with.

When it comes to Maintainability, MVVM and PresentationModel are an evolotion of previous UI architectures, and that's because the SRP principle is kept very strictly. Write enough code in MVVM and you'll see what I mean.

Blendability

Another Feature where MVVM is really strong is Blendability.
Since all of the application state is preserved within the ViewModel, it is easy to fake data for design time, which allows enourmous boost to productivity. 
This is impossible to create in PassiveView, MVP or MVC, because in all of those architectures the controller has to actively put data inside the view. In MVVM the data just "jumps" to the View and therefore can be mocked.

Testability

This is indeed a place where PassiveView is superior to MVVM. If 100% Unit Tests coverage of UI is crucial to you then it's a big deal. 
In most situations however, the coverage that MVVM allows you is more than enough, and you'll usually add another tier of testing using regular UI Testing (which you'd end up doing in PassiveView also btw).

I think that Testability is the less important of the three features. Sorted by importance, it's Maintainability, Blendablilty, and Testability.

Where is MVVM not the right choice?

I've participated in ~ 15 WPF &amp; Silverlight Projects the last year, all of which MVVM fit perfectly. I think that in places where the presentation logic is extremely big, such as in games, MVVM might not be the right choice.
Other than games, I can't really think of an application category that wouldn't go best with MVVM, other than special situations like RS Conley mentioned.

blocks|key|3198599|text|在过去的几个月里，我一直致力于使用WP7+(Silverlight)+MVVM应用程序来实现MVP。我相信我已经想出了一个很好的解决方案，它充分利用了这两个领域的优势。缺点是有相当多的“脚手架”代码。优点是一个最有价值的框架，其中模型和演示者层应该在WP7、WM和安卓(给定MonoDroid)之间重用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3198600|我使用了这里描述的MVP-VM+-+http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html作为我设计的基础。|offset|length|3198601|模型就是模型，不需要任何说明。它包含数据类、业务逻辑和服务，并且不引用任何特定于UI的内容。|3198602|Presenter和View界面遵循被动视图模式。|3198603|视图接口主要由事件、一些属性和一些方法组成。在Presenter和View之间传递的所有内容都不是特定于UI的。|3198604|视图实现是PhoneApplicationPage+(或WPF+form)、PageViewModel和ViewFacade的组合。|3198605|ViewFacade才是真正实现视图接口的对象。它负责协调页面和ViewModel。它从页面中冒泡事件，使它们中的大多数异步触发，演示者捕获这些事件。它还将任何特定于UI的事件参数转换为非UI参数。从Presenter到ViewFacade的任何内容都将检查UI线程安全性，并正确调用。属性通常是数据，并传递给ViewModel。|3198606|将视图接口实现(ViewFacade)与实际的UI类(页面、表单等)分开有助于保持视图三元组类之间的职责不同。例如，ViewFacade的主要用途之一是作为线程同步发生的层。|3198607|页面/+ViewModel的执行方式与您通常一样，但是，命令是通过ViewFacade向演示者冒泡的事件。|3198608|优势|style|BOLD|3198609|MVP设计和平台间的可重用性。|3198610|使用MVVM轻松绑定数据。|3198611|IMO，MVP更符合逻辑，更容易概念化。|3198612|的劣势|3198613|页面事件和ViewFacade事件、ViewModel属性和ViewFacade属性之间的代码重复。|3198614|简单的情况下可能会有比实际需要多得多的代码。|3198615|最后，你不得不问自己，MVP是否值得你付出额外的努力。更快的开发周期比跨平台的可重用性和增强的可测试性更重要吗？|3198616|entityMap|0|LINK|mutability|MUTABLE|url|http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html^0|0|I|21|0|0|0|0|0|0|0|0|0|0|2|0|0|0|0|1|2|0|0|1E|0|0|M|0|0|1K|0^^$0|@$1|2|3|4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1K|8|@]|9|@$D|1L|E|1M|1|1N]]|A|$]]|$1|F|3|G|5|6|7|1O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1P|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1R|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1S|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1T|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1U|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1V|8|@$D|1W|E|1X|V|W]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|20|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|21|8|@$D|22|E|23|V|W]]|9|@]|A|$]]|$1|15|3|16|5|6|7|24|8|@$D|25|E|26|V|W]]|9|@]|A|$]]|$1|17|3|18|5|6|7|27|8|@$D|28|E|29|V|W]]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2A|8|@$D|2B|E|2C|V|W]]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]]|1C|$1D|$5|1E|1F|1G|A|$1H|1I]]]]

I've been working on implementing MVP with a WP7 (Silverlight) MVVM app for the past couple months. I believe I've managed to come up with a good working solution that leverages the best of both worlds. The downside is that there is a fair bit of "scaffolding" code. The upside is an MVP framework where the Model &amp; Presenter tiers should be reusable between WP7, WM, and Android (given MonoDroid).

I used MVP-VM as described here - <a href="http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html" rel="nofollow">http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html</a> - as a basis for my design.

The Model is the model and shouldn't need any clarification. It contains the data classes, business logic, and services, and doesn't reference anything UI-specific.

The Presenters and View interfaces follow the Passive View pattern.

View interfaces are comprised mostly of events, some properties, and a few methods. Everything that passes between the Presenter and View is non-UI specific.

View implementations are a triad of PhoneApplicationPage (or WPF form), PageViewModel, and a ViewFacade.

The ViewFacade is what actually implements the View interface. It is responsible for coordinating the Page and ViewModel. It bubbles up events from the Page, makes most of them fire asynchronously, which the Presenter catches. It also transforms any UI-specific event parameters into non-UI parameters. Anything coming from the Presenter to the ViewFacade is checked for UI thread safety and invoked properly. The properties are usually data and are passed on to the ViewModel.

Keeping the View interface implementation (ViewFacade) separate from the actual UI class (Page, Form, etc) helps to keep the responsibilities distinct between the View triad classes. For instance, one of the ViewFacade's primary purposes is to be the layer where thread synchronization happens.

The Page / ViewModel are done mostly as you would normally do, however, the commands are events which bubble up via the ViewFacade to the Presenter.

Advantages

MVP design &amp; reusability between platforms.

Easy databinding with MVVM.

IMO, MVP is more logical and easier to conceptualize.

Disadvantages

Duplication of code between Page events and ViewFacade events, ViewModel properties and ViewFacade properties.

Simple cases can have a lot more code than is really necessary.

In the end you have to ask yourself if MVP is worth the extra effort. Is a quicker development cycle more important than reusability across platforms and enhanced testability?

On page 374 in the book <a href="https://rads.stackoverflow.com/amzn/click/com/073562609X" rel="noreferrer" rel="nofollow noreferrer">Microsoft .NET Architecting Applications for the Enterprise</a>, there is a chart regarding the evolution of patterns for the presentation layer and their impact on platforms (figure 7-14).

In addition to showing the evolution from the original MVC pattern, to the more modern variants, that chart also shows that the following modern patterns can be applied across the following technologies:

<ol>
<li>Model2 (MVC) 

<ul>
<li>Web Only</li>
</ul></li>
<li>Passive View (MVP)

<ul>
<li>Web</li>
<li>WinForms</li>
<li>WPF</li>
</ul></li>
<li>Supervising Controller (MVP)

<ul>
<li>Web</li>
<li>WinForms</li>
<li>WPF</li>
</ul></li>
<li>MVVM (Presentation Model)

<ul>
<li>WPF Only</li>
</ul></li>
</ol>

Note: One other recent pattern of interest lately not in that chart is <a href="http://www.atomicobject.com/files/PresenterFirstAgile2006.pdf" rel="noreferrer">Presenter First (MVP)</a> which was envisioned to be more accommodating of TDD. 

<hr>

From what I understand if one develops with WPF, then the MVVM pattern is the de facto choice (kind of like Model2 is for web development). That said, it appears nothing prevents one from using Passive View, Supervising Controller, or Presenter First in a WPF app. Such an approach would result in an application that doesn't really care if the front end is WPF, WinForms, or the Web. It appears that these MVP variants allow more flexibility.

However, does aiming for UI-platform-agnostic flexibility (that might not be needed) come at the cost of making WPF development much more difficult and lose out on a portion of the features/power that WPF offers? So much so that the costs outweigh the benefits?

In other words, is MVVM so great that one shouldn't consider other alternatives in WPF applications?

Always use MVVM in a WPF app, or are alternative patterns still practical/useful?

单元测试

虚拟机

在一书的第374页上，有一张关于表示层模式的演变及其对平台的影响的图表(图7-14)。除了显示从原始MVC模式到更现代变体的演变之外，该图表还显示了以下现代模式可以应用于以下技术：Model2 (MVC) Web Only​Passive View (MVP) WebWinFormsWPF​Supervising控制器...

问总是在WPF应用程序中使用MVVM，或者替代模式仍然实用/有用吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问总是在WPF应用程序中使用MVVM，或者替代模式仍然实用/有用吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问总是在WPF应用程序中使用MVVM，或者替代模式仍然实用/有用吗？
EN