WPF综合指导：MVVM vs MVP [英] Composite Guidance for WPF : MVVM vs MVP

问题描述

我很困惑也许你可以帮助我：）

我一直在追踪CAG的指导，发现MVP模式非常自然。
假设我有一个UI就绪的模型（例如：implements INotifyPropertyChanged），我使用演示者将该模型绑定到视图（演示者知道视图的界面），使我的Code-Behind尽可能小仅处理没有ICommand的控件的Bindings（模型和命令）属性（或方法）或事件，在这种情况下立即被委派给演示者。

1. 过了一段时间，我发现了MVVM模式，到目前为止，它不包括我。
   就我的方法而言，只有当我的Model不是UI就绪时，才会使用MVVM。但是，保持演示者并且只使用新的模型会更合理，我不明白这种用法会丢失什么。
   我知道我错过了一些东西，但它是什么：）。




2. 此外，当您的View是通用的并且可以处理多种模型例如在PropertyGrid中）。 ViewModel建议与DataTemplate一起使用，但在这种情况下，您无法为Model中的每个实体创建一个模板，只需要在运行时进行调查，那么你会推荐什么？




3. 在观看Josh Smith谈论MVVM时，在 screencast ，我感觉到模型在ViewModel中的暴露是违反DRY（不要重复你自己），这真的是不可避免的吗？令人惊讶的是，我没有人争论这个比较火焰 ADO.Net动态数据元数据类现在得到了。

希望很清楚

谢谢

Ariel

$ b $关于＃3，很多人会使用另一层间接论证，说模型的变化不会影响视图。虽然这在技术上是正确的，但不是这样做的真正原因。

如果您将模型视为您返回的实体，例如数据访问层或服务（这通常被认为是这些），你开始看到为什么需要一个ViewModel。一个ViewModel被设计为 扩展模型与行为视图需要 。

例如。如果您想要更改属性，并通过绑定通知此更改的视图，该属性需要提高某种形式的NotifyPropertyChanged，以便视图可以做出反应。这是您典型的模式不会有的行为。

另外，我们假设你有一个集合，你想标记集合中的每个项目当用户单击视图中该项目旁边的复选标记时，该值为布尔值。你可能需要一个IsSelected属性。这是模型不应该提供的行为。

然而，我看到你来自哪里...我一开始就有一个问题。我第一次将模型的内容复制并粘贴到我的视图模型中，我的胃转动了，但你只需要和平，因为对于你的视图工作，这将需要一个额外的行为，一个模型应该不提供

无论这是多么干，强制您的WCF类型或LINQ to SQL类型（或任何您最喜欢的ORM）实现INotifyProperyChanged更糟糕。 >

I am confused. Maybe you can help me :)

I have been following the guidance of CAG and found the MVP pattern very natural to me. Suppose I have a UI-ready Model (for example : implements INotifyPropertyChanged), I use the presenter to bind this Model to a view (presenter knows an interface of the view), keeping my Code-Behind as small as possible handling only Bindings (Model and Commands) properties (or methods) or events for controls that don't have ICommand and in this case immediately being delegated to the presenter.

1. After a while I've discovered the MVVM pattern, and so far it eludes me. As far as I can tell in my approach I would use MVVM only when my Model is not UI-ready. But would it be more reasonable to keep the presenter and just use a new Model, I fail to understand what do I lose with this kind of usage. I know I am missing something, but what is it :).

2. Also when your View is generic and can handle many kinds of Models (such as in a PropertyGrid). ViewModel is recommended to be used with a DataTemplate, but in this case you just can't create a Template for each entity in your Model, it is just need to be investigated in runtime, what would you recommend?

3. While watching Josh Smith talking about MVVM in a screencast, I got a feeling that the re exposing of the Model in the ViewModel is violating DRY (do not repeat yourself), is it really unavoidable? it surprises me nobody his arguing about it in comparison for the flames ADO.Net Dynamic Data metadata classes are getting nowadays.

Hope it was clear enough

Thanks

Ariel

解决方案

Regarding #3, a lot of people will use the "another layer of indirection" argument, saying that changes in the model won't affect the view. While this is technically correct, it's not the real reason to do something like this.

If you consider the Model as the entities you get back from, say, a data access layer or a service (which is what these are generally considered) you begin to see why you need a ViewModel. A ViewModel is designed to extend the model with behaviors the View needs.

For example. If you want to be able to change a property and have the View notified of this change through binding, the property needs to raise some form of NotifyPropertyChanged so that the view can react. This is behavior that your typical model won't have.

In another example, let's say you have a collection and you'd like to flag each item in the collection with a boolean value when a user clicks a checkmark next to that item in the view. You'd need an "IsSelected" property, probably. This is a behavior that the Model shouldn't have to provide.

However I see where you are coming from... I definitely had a problem with this at first. The first time I copy and pasted the contents of a model into my viewmodel, my stomach turned, but you just have to make peace with the fact that for your View to work, it's going to need this extra bit of behavior that a Model shouldn't provide.

No matter how un-DRY this is, forcing your WCF types or LINQ to SQL types (or whatever your favorite ORM is) to implement INotifyProperyChanged is worse.

这篇关于WPF综合指导：MVVM vs MVP的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！