始终在 WPF 应用程序中使用 MVVM，或者替代模式仍然实用/有用吗？
本书第 374 页Microsoft .NET 为企业构建应用程序< /em>，有一个关于表示层模式的演变及其对平台的影响的图表（图 7-14）。
除了显示从原始 MVC 模式到更现代的变体的演变之外，该图表还显示以下现代模式可以跨以下技术应用：
- Model2 (MVC)
- 仅限网络
- 被动视图 (MVP)
- 网络
- WinForms
- WPF
- 监督控制器 (MVP)
- 网络
- WinForms
- WPF
- MVVM（表示模型）
- 仅限 WPF
注意： 最近未出现在该图表中的另一种最近令人感兴趣的模式是 演示者优先 (MVP) 被认为更适合 TDD。
据我了解，如果使用 WPF 进行开发，那么 MVVM 模式是事实上的选择（有点像用于 Web 开发的 Model2）。也就是说，似乎没有什么可以阻止人们在 WPF 应用程序中使用被动视图、监督控制器或Presenter First。这种方法会导致应用程序并不真正关心前端是 WPF、WinForms 还是 Web。看来这些 MVP 变体提供了更大的灵活性。
但是，追求与 UI 平台无关的灵活性（可能不需要）是否会导致 WPF 开发变得更加困难并失去 WPF 提供的部分功能/功能？如此之多以至于成本超过收益？
换句话说，MVVM 是否如此出色以至于人们不应该在 WPF 应用程序中考虑其他替代方案？
On page 374 in the book Microsoft .NET Architecting Applications for the Enterprise, 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:
- Model2 (MVC)
- Web Only
- Passive View (MVP)
- Web
- WinForms
- WPF
- Supervising Controller (MVP)
- Web
- WinForms
- WPF
- MVVM (Presentation Model)
- WPF Only
Note: One other recent pattern of interest lately not in that chart is Presenter First (MVP) which was envisioned to be more accommodating of TDD.
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据MVVM for WPF中包含的文档（一般介绍的第2页）
访问 Martin's Fowler 的网站并查找 演示模型，我们有这个
对于我自己的金属切削 CAD-CAM 应用程序，我使用被动视图。这样做的原因是
工具包，因为该软件已经
自1985年以来不断发展
并看到了一些重大变化
底层工具、API，甚至
语言本身。
前三个问题可以通过 MVVM、表示模型、监督控制器模式来处理。但只有被动观点解决了#4。
正如 Martin Fowler 所说，只有被动视图不需要任何同步方法。 MVVM 是 WPF 演示模型的实现。您依赖 XAML 接口将视图模型中的视图状态与视图本身联系起来。因此，如果稍后您更改 UI 或其 API，那么您的视图模型也会更改。
相比之下，被动视图仅要求新的 UI 元素实现视图接口。它们实际连接到什么并不重要，因为表单或控件实现会正确响应。
但代价是在实现视图的新元素时需要执行额外的步骤。您必须决定如何将它们呈现给演示者以及以什么抽象级别呈现。对于某些项目或某些类型的 UI（如对话框）来说，它已经足够了。
对于您关于 MVVM 是 WPF 的方式的问题的简短回答，答案是否定的，事实并非如此。这是一个需要根据应用程序开发的其他问题来考虑的工具。
According to the included documentation in MVVM for WPF (page 2 of the general introduction)
Going to Martin's Fowler's website and looking up Presentation Model we have this
For my own metal cutting CAD-CAM application I use Passive View. The reasons for this are
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.
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.
@RS Conley 的回答对这个主题进行了非常广泛的探讨，我同意大多数内容。我唯一认为不同的是底线。
MVVM 是适用于 WPF 中 95% 应用程序的架构。
选择任何其他架构都意味着满足于低于您所能获得的最佳架构。在 RS Conley 的情况下，被动视图可能是最好的选择，但这与正常情况相去甚远。
作为理解 MVVM 为何更好的一种方式，让我们看看当他采用 PassiveView 方法时他会失去什么。
可维护性
在被动视图中，ViewModel 知道 IView，这意味着不保留 SRP（单一职责原则）。 PassiveView 中的控制器直接与模型和视图交互，因此正在做两件完全不同的事情！。
在MVVM下，作为应用程序核心的ViewModel只关心一个问题，那就是包含应用程序的状态和逻辑。这种代码的可维护性确实大大优于 PassiveView、MVP 或 MVC。
确实，PassiveView 在自动化测试覆盖范围方面更好，但恕我直言，代码的良好可维护性更为重要。
可测试性帮助您确保不会破坏代码，而可维护性则帮助您不要从一开始就构建有问题的代码。
说到可维护性，MVVM 和PresentationModel 是之前UI 架构的演变，这是因为SRP 原则得到了非常严格的遵守。在 MVVM 中编写足够的代码，您就会明白我的意思。
可混合性
MVVM 真正强大的另一个功能是可混合性。
由于所有应用程序状态都保留在 ViewModel 中，因此很容易在设计时伪造数据，从而极大地提高生产力。
这是不可能在 PassiveView、MVP 或 MVC 中创建的，因为在所有这些架构中，控制器必须主动将数据放入视图中。在 MVVM 中，数据只是“跳转”到视图，因此可以被模拟。
可测试性
这确实是PassiveView优于MVVM的地方。如果 100% 的 UI 单元测试覆盖率对您来说至关重要，那么这就是一件大事。
然而，在大多数情况下，MVVM 允许的覆盖范围绰绰有余，您通常会使用常规 UI 测试添加另一层测试（顺便说一句，您最终也会在 PassiveView 中执行此操作）。
我认为可测试性是三个特性中不太重要的一个。按重要性排序，它是可维护性、可混合性和可测试性。
MVVM 哪里不是正确的选择？
我参加过 ~ 15 WPF &去年的Silverlight项目，所有这些都与MVVM完美契合。我认为在表示逻辑非常大的地方，比如游戏中，MVVM 可能不是正确的选择。
除了游戏之外，除了 RS Conley 提到的特殊情况之外，我实在想不出还有哪个应用程序类别不适合使用 MVVM。
@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&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 & 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.
在过去的几个月里，我一直致力于使用 WP7 (Silverlight) MVVM 应用程序实现 MVP。我相信我已经设法想出一个很好的工作解决方案，充分利用了两全其美的优势。缺点是有相当多的“脚手架”代码。优点是 MVP 框架中的模型和模型。 Presenter 层应该可以在 WP7、WM 和 Android（给定 MonoDroid）之间重用。
我使用了 MVP-VM，如下所述 - http:// aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html - 作为我设计的基础。
模型就是模型，不需要任何澄清。它包含数据类、业务逻辑和服务，并且不引用任何特定于 UI 的内容。
Presenters 和 View 界面遵循被动视图模式。
视图接口主要由事件、一些属性和一些方法组成。 Presenter 和 View 之间传递的所有内容都是非 UI 特定的。
视图实现是由 PhoneApplicationPage（或 WPF 表单）、PageViewModel 和 ViewFacade 组成的三元组。
ViewFacade 是 View 接口的实际实现。它负责协调Page 和ViewModel。它从页面中冒出事件，使大多数事件异步触发，并由演示者捕获。它还将任何特定于 UI 的事件参数转换为非 UI 参数。从 Presenter 到 ViewFacade 的任何内容都会检查 UI 线程安全性并正确调用。属性通常是数据并传递到 ViewModel。
将 View 接口实现 (ViewFacade) 与实际 UI 类（Page、Form 等）分开有助于保持 View 三元组类之间的职责不同。例如，ViewFacade 的主要目的之一是成为发生线程同步的层。
页面/视图模型大部分都像平常一样完成，但是，命令是通过 ViewFacade 冒泡到 Presenter 的事件。
优点
MVP设计与实现平台之间的可重用性。
与 MVVM 轻松进行数据绑定。
在我看来，MVP 更符合逻辑，更容易概念化。
缺点
Page 事件和 ViewFacade 事件、ViewModel 属性和 ViewFacade 属性之间存在重复代码。
简单情况下的代码可能比实际需要的多得多。
最后你必须问自己 MVP 是否值得付出额外的努力。更快的开发周期是否比跨平台的可重用性和增强的可测试性更重要？
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 & Presenter tiers should be reusable between WP7, WM, and Android (given MonoDroid).
I used MVP-VM as described here - http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html - 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 & 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?