本文是小编为大家收集整理的关于WPF的复合指导：MVVM vs MVP的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
我很困惑.也许您可以帮助我:)
我一直在遵循CAG的指导，发现MVP模式对我来说很自然. 假设我有一个UI-Ready模型(例如:实现InotifyPropertychanged)，我使用演示者将此模型绑定到视图(主持人知道视图的接口)，使我的代码范围保持尽可能小的处理(仅处理绑定)(模型和命令)属性(或方法)或没有ICommand的控件的事件，在这种情况下，立即将其委派给了主持人.
-
过了一会儿，我发现了MVVM模式，到目前为止，它使我感到不安. 据我所知，在我的方法中，我只有在我的模型不准备就绪时才使用MVVM.但是，保留主持人并使用新模型会更合理，我无法理解这种用法我会失去什么. 我知道我缺少什么，但是是什么:).
-
当您的视图是通用的时，并且可以处理多种模型(例如在PropertyGrid中).建议将ViewModel与DatateMplate一起使用，但是在这种情况下，您只是无法为模型中的每个实体创建模板，只需要在运行时进行研究，您会推荐什么?
-
看着乔什·史密斯(Josh Smith)在A 屏幕截图，我感觉到在ViewModel中曝光模型正在违反干燥(不要重复自己)，这真的不可避免吗? it surprises me nobody his arguing about it in comparison for the flames ado.net动态数据元数据类正在获取现在.
希望它已经足够清楚
谢谢
ariel
推荐答案
关于#3，许多人会使用"另一层间接"论点，称模型中的变化不会影响视图.虽然这在技术上是正确的，但这不是这样做的真正原因.
如果您将模型视为您从数据访问层或服务(通常考虑的)中回来的实体，则开始了解为什么需要ViewModel. ViewModel设计为 使用行为扩展模型.
例如.如果您想能够更改属性并通过绑定使此更改通知此属性，则该属性需要筹集某种形式的通知Propertychanged，以便该视图可以反应.这是您典型模型将没有的行为.
在另一个示例中，假设您有一个集合，当用户单击视图中该项目旁边的复选标记时，您想用布尔值标记收藏集中的每个项目.您可能需要一个"恢复"属性.这是模型不必提供的行为.
但是，我看到您来自哪里...一开始我肯定有一个问题.我第一次将模型的内容复制并粘贴到我的ViewModel中时，我的胃转过身来，但是您只需要和平，即为了使您的观点工作，它将需要模型不应该的这种额外的行为't提供.
不管这是多么干燥，将您的WCF类型或LINQ迫使SQL类型(或任何您喜欢的ORM)实现InotifyProperyChanged都更糟.
其他推荐答案
ad.3.看来您通过在ViewModel中公开模型来重复自己，但是您真正要做的就是抽象模型，因此视图仅知道此抽象(视图仅知道ViewModel).
这是因为更改模型不应破坏视图.同样，您的模型可以实现从不同来源获取数据的许多不同的服务.在这种情况下，您不想查看所有内容，因此您创建另一个抽象 - viewModel.
其他推荐答案
除了上面的评论.我想分享我对差异的一些个人理解.
通常，在MVP中，您具有视图接口，例如. iview，抽象实际视图并将数据绑定到那些实际视图.相反，在MVVM中，您通常使用实际视图的数据台面，例如. XAML用户控件，用于进行数据指标，类似于MVP中的IView.因此，假设不准确，两种模式上的绑定相似.
主要区别在于主持人与ViewModel部分.视图模型与演示者非常不同，这是用于交换UI和模型之间数据的桥梁.实际上，它的名称是一种视图模型.在ViewModel中公开的数据主要用于UI过程.因此，从我的理解中，在MVVM中，ViewModel是观点的抽象.与此相反，MVP主要使用iView来抽象视图.因此，通常MVVM中的层数几乎没有MVP，因此您可以在MVVM中编写更少的代码来完成相同的工作:
mvvm:model -viewModel(表示实际视图，即UI) - 实际视图
MVP:模型 - 演示者(用于在模型和UI之间交换数据的桥梁) - iview(表示实际视图，即UI) - 实际视图
MVVM比MVP的优势主要基于Microsoft Products的以下2个出色功能，
-
在WPF中命令.尽管已经有一些在Silverlight Runtime中没有某些实现
-
wpf和silverlight中的datacontext.
问题描述
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.
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 :).
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?
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.
其他推荐答案
Ad.3. It may seem that you repeat yourself by exposing Model in ViewModel, but what you really do is abstracting the Model, so that View knows only about this abstraction (View knows only about ViewModel).
This is because changes to Model shouldn't break the View. Also, your Model can be implemented as many different services that get data from different sources. In this case you wouldn't like View to know about all of them, so you create another abstraction - ViewModel.
其他推荐答案
Besides the comments above. I would like to share some of my personal understanding on the difference.
Normally in MVP you have an interface of View, eg. IView, to abstract actual views and bind data to those actual views. In MVVM, instead, you normally use the DataContext of an actual view, eg. a XAML user control, to do databinding, which is similar to the IView in MVP. So let's say, inaccurately, the binding is similar on both patterns.
The major difference is on the Presenter vs ViewModel part. A view model is very different to a presenter which is a bridge for exchanging data between UI and model. It is actually, as what its name means, a model of the view. The data exposed in a ViewModel is mainly for UI process. So from my understanding, in MVVM, the ViewModel is an abstraction of views. In contrary to it, MVP mainly uses IView to abstract views. So normally there are few layers in MVVM than MVP and hence you can write less code to do the same job in MVVM:
MVVM: Model - ViewModel(represents actual views, ie. UI) - Actual Views
MVP: Model - Presenter(a bridge for exchanging data between model and UI) - IView(represents actual views, ie. UI) - Actual Views
The MVVM's advantage over MVP is mostly based on the following 2 great features in Microsoft products,
Commanding in WPF. It could be avilable in Silverlight in the future although there are already some implementations which are not in the Silverlight runtime
DataContext in WPF and Silverlight.
更多相关问答
联系站长