问题描述
我的名字是来自西班牙的Jesús，我是一名.NET开发人员，几天前我刚刚发现了这个伟大的网站。我对MVVM有一些疑问
我三个月前开始使用WPF，我已经学会了MVP模式。
MVP是非常好的，因为你可以使应用程序结构很好。
我开始看到MVVM，但每个人都用自己的方法使用模式。
每个博主都是在WPF的博客中谈论MVVM，但每个实现都是截然不同的。
我现在关注的是在CodePlex上使用MVVM工具包的实现，但是我有疑问不能找到太多的信息。
我认为MVVM是MVP的一个变体。
使用MVP，每个视图都有一个主持人视图的工作。
在MVVM中，它是一样的，但使用命令，只要你可以。
我也看到，如果哟你需要一个事件，就像MVP一样;将该事件委托给演示者/ View-Model，即如果不是视图的工作（例如更新UI）。
另一方面， View-Model没有View参考，所以我必须更加努力地使用数据绑定。
你必须使用DelegateCommands（与RelayCommands是一样的，对吗？） p>
Uhm ...更多问题...使用具有两个视图/用户控件的相同视图模型是否安全？
哦，昨天遇到一个问题，当我在玩MVVM。
我创建了一个 CommandReference 我的命令键绑定的东西，我分配了这个引用到我的按钮的命令属性，好吧， CanExecuted 第一次工作，但它没有更新<$ c $当$ code> CanExecuted 为true时，c> IsEnabled 属性。我通过将命令直接绑定到按钮而不使用引用来修复它。问题是：为什么一些代码将引用链接到对象，以及为什么其他代码直接绑定命令？
我应该学习什么与MVVM相关的东西？ （我昨天看到一些被称为附加行为的东西，但我不知道是什么）。
我正在重写一个笔记本应用程序，我使用MVP开发，但现在与MVVM。我将使用命令（使用DelegateCommand）替换事件，消除View-Model上的视图引用，我认为这是因为我看到的MVVM的示例很像MVP。
嗯，如果你指出我有这种模式的所有误会，我会很感激。
谢谢你，将来我会帮助下一个MVVM新手：）
哇，我将尝试回答你的许多问题，涉及一个特定的技术或框架，尽可能...抱歉，如果我想念一些（子弹点将有所帮助）
- MVVM不一定是MVP的变化。 MVP本身是一个模糊的加载术语。 Martin Fowler通过来实现正义。 MVVM独立，但与MVP模式共享一些概念。像所有UI模式一样，它尽可能地将视图逻辑与业务逻辑分开。 MVVM与MVP不同的是它创建了纯粹用于演示目的的模型（或）。这与MVP模式如何解决分离问题不同。
- - MVVM比被动视图更接近监督控制器模式。这里唯一真正的区别可能是MVVM明确地为视图创建了一个模型（因此View Model）
- ViewModel没有对视图的引用，因为它用作视图数据的模型。这是一个适当的抽象。如果它也引用了这个视图，那么你将有一个双向的依赖关系来创建额外的耦合。此外，ViewModel本身没有真正的理由来了解View。它的唯一工作就是从模型中抽取模型（实际的商业模式）。
- DelegateCommands vs. RelayCommands - 我相信你在这里获得技术特性，所以我真的不能回答一个。
- 您不应该为多个视图设计ViewModel。这只会产生复杂性，因为如果您更改视图，则必须调查哪些ViewModel可能会受到影响并更改这些视图。这可能会导致级联效应。您的行为应该在商业模式中，而不是ViewModel，所以ViewModel只需要包含翻译和事件处理逻辑。
- 然而，这是一个好主意， 1比例的ViewModel与UserControl，因为UserControls应该能够在屏幕上作为自主单元。
- 对于其他技术的具体问题，抱歉，我没有答案。但是，我可以建议您仔细阅读我为提供的链接， 和。为UI模式提供一些上下文，并且是技术中立的。
重要的是要记住，虽然MVVM适合于解决采用WPF提出的问题，这不是技术具体的模式。如果您深入了解具体的实施过程，而不了解基本哲学，您可能会在早期发生一些非常大的错误，只有在太晚才能发现。不幸的是，MVVM不是一个很好的文件格式，当你说出每个人都有自己的想法，你是对的。
这不是一个革命性的模式已经存在多年不同名称），但WPF的数据绑定使其成为现在可行的解决方案，因此它享有新的人气。这是一个很好的模式，但它不是教义。接触您所面对的每一个指令，并提供适当的怀疑。
编辑
是正确的，当说明数据绑定是WPF中非常重要的一部分。我表示WPF的数据绑定使MVVM解决方案成为可能，但是绑定本身就非常强大，所以采用MVVM的增长速度要比围绕它的文献要快。
My name is Jesús from Spain, I'm a .NET developer and I just discovered this great web few days ago.
I have some questions about the MVVM pattern and I will be glad if you can answer them.
I started using WPF three months ago and I've learned the MVP pattern.
MVP is so good because you can structure the application so well.
I started seeing MVVM everywhere, but everyone is using the pattern by his own method.
Every blogger is talking about MVVM in their WPF's blogs but every implementation is distinct.
I'm focused now with the implementations that use the MVVM toolkit on CodePlex, but I have questions and I can't find too much information.
I think that MVVM is a variation of MVP.
With MVP every view has a presenter that does the view's job.
In MVVM it's the same thing but using commands whenever you can.
I also saw that if you need an event, it's like with MVP; delegating the event to the presenter / View-Model, that is if it's not a job for the view (such as updating the UI).
On the other hand, the View-Model doesn't has a View reference so I have to play harder with data-bindings.
You have to use the DelegateCommands (that are the same thing as RelayCommands, right?).
Uhm... more questions... Is it safe to use the same View-Model with two views / user-controls?
Oh... I ran into a problem yesterday when I was playing MVVM.
I created a CommandReference of my command for the key-binding thing and I assigned this reference to the command property of my button, well, the CanExecuted worked the first time but it didn't update the IsEnabled property when the CanExecuted was true. I fixed it by binding the command directly to the button and not using the reference. The question is: Why some code is linking the reference to the objects and why other code is binding the command directly?
What things related with MVVM should I learn? (I saw something called attached behaviors yesterday but I don't know what is that).
I'm rewriting a note tacking app that I developed using MVP but now with the MVVM. I will replace the events with commands (using the DelegateCommand), eliminate the views references on the View-Model and I think that's all because the examples that I saw of MVVM is much like MVP.
Well, I will appreciate if you point me to all the misunderstandings that I have with this pattern.
Thank you and in the future I will help the next MVVM novices :)
Wow, I'm going to try to answer as many of your questions, that don't involve a specific technology or framework, as possible... sorry if I miss some (bullet points would help)
- MVVM is not necessarily a variation of MVP. MVP itself is an ambiguous, loaded term. Martin Fowler did it justice by splitting it into two patterns. MVVM stands on its own, but shares some concepts with the MVP patterns. Like all UI patterns, it seeks to separate view logic from business logic as much as possible. What the MVVM does that is different from MVP is it creates a model purely for the purpose of presentation (or a presentation model). This is different than how MVP patterns solve the separation problem.
- Passive View - With the passive view, the view never sees the model.
- Supervising Controller - MVVM is much closer to the Supervising Controller pattern than to the Passive View. The only real difference here could be that the MVVM explicitly creates a model just for the view (hence the term "View Model")
- The ViewModel doesn't have a reference to the view, because it serves as a model for the data of the view. This is an appropriate abstraction. If it also referenced the view, you would have a two-way dependency which would create additional coupling. Also, the ViewModel itself doesn't have a real reason to be aware of the View. Its only job is to abstract the model (the actual business model) from the view.
- DelegateCommands vs. RelayCommands - I believe you're getting technology specific here, so I can't really answer that one well.
- You should not design a ViewModel for more than one view. This only creates coplexity inasmuch as if you change a view, you will have to investigate which ViewModels might be affected and change those. This could possibly lead to a cascade effect. Your behavior should be in the business model, not the ViewModel, so the ViewModel need only contain translation and event handling logic.
- It would be a good idea, however, to have a 1:1 ratio of ViewModel to UserControl, since UserControls are supposed to be able to act as autonomous units on your screen.
- As for the other technology specific questions, sorry, I have no answer. I can suggest, however, that you carefully read the links I included for the Passive View, Supervising Controller, and Presentation Model. The provide some context to UI patterns, and are technology neutral.
It's important to keep in mind that, while MVVM is suited to solving problems posed by adopting WPF, it is not a technology specific pattern. If you dive too deeply into a specific implementation without understanding the underlying philosophy, you could make some very big mistakes early on, and only discover them after it's too late. Unfortunately, MVVM is not a well documented pattern, and you are right when you stated that everyone has their own idea of what it is.
It's not a revolutionary pattern (it has been around for years under different names), but the data binding of WPF makes it a viable solution now, and so it's enjoying newfound popularity. It's a good pattern, but it's not doctrine. Approach every "dictate" you're faced with with the appropriate amount of skepticism.
EDIT
@micahtan is right when stating that data bind is a very important piece in WPF. I stated that WPF's data binding enables the MVVM solution, but the binding itself is very powerful, which is why adoption of MVVM is growing faster than the literature surrounding it.
这篇关于我有一些关于MVVM模式的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！