This project has moved and is read-only. For the latest updates, please go here.

Is this really MVVM or just MVC or MVP ?

Jul 15, 2011 at 4:29 PM

It's getting so dizzy with all the patterns. I stumbled on this looking for ways to open dialogs using WPF MVVM and what are the proper ways to do this.

I download the code and I see controllers, and viewmodels and the base viewmodel class KNOWS about the views via an interface! DataTemplates are NOT being used to link a viewmodel to a view. I see interfaces for every view even if most seem empty.

This feels more hybrid MVC/MVP and just that the "Model" is being called a "ViewModel" for the sake of wanting to call this MVVM.  The framework dll requires references to the WPF presentation layer dlls.

In the email app, a dialog is being show because their is code behind in the view. So any designer of this app when building xaml screens, would need to know to CODE this. Essentially the viewmodel is making a call BACK to the view. Sure it's abstracted via the interface, but they still know something about each other.

Don't get me wrong, this seems like a nice framework, but I have to disagree on it being called MVVM, or at least, this is not a pure MVVM design since it seems there are shortcuts for getting certain problems solved.

Jul 16, 2011 at 3:18 PM

The principles of MVVM are about clear separation of the presentation, application, and domain layers. I see WAF as an interpretation of such principles and my opinion is that it achieves them well.

All the ViewModel knows is that it needs a View and this is achieved through a loosely coupled interface and dependency injection. You can hardly claim that the ViewModel knows anything about the view (in simple cases - see next point).

That being said, I wasn't particularly comfortable about how dialogs/popup windows were handled. In these situations I felt that the View knew too much about the application layer in terms of how it is being displayed and the life cycle of a particular application screen. Fortunately, WAF is very flexible and in no way prescriptive on how it should be used. 

This meant it was remarkably easy to write a new ViewModel class that does not require the View to be injected into the constructor and instead relies on the Presentation layer binding Views to appropriate ViewModels using DataTemplates as you suggest. I have also introduced a Presenter class which deals with the life cycle of a ViewModel - allowing any particular View to be displayed 'embedded' or in a new window/popup without either the View or ViewModel having any knowledge of how it is being displayed. This is now the responsibility of the top level of the Application layer (i.e. the Controller) with the help of the Presenter class.

The approach I take solves your concerns highlighted in your example from the email app. It means that all Views can be designed as UserControls rather than the Presentation layer having to have prior knowledge of how the Application layer will use it (i.e. designing the view as a Window).

In terms of WAF referencing PresentationFramework this is simply because WAF provides functionality for all three layers. If you were to be really picky about this you could simply split up the framework into WAFModel, WAFApplication, and WAFPresentation assemblies. I assume that the author didn't do this because it is overly complex and unnecessary just for the sake of being more technically 'correct'.

Which leads me to my final point: WAF, in my opinion, takes a pragmatic design philosophy. When it comes to developing real-world applications, this is exactly what I'm looking for.


Jul 16, 2011 at 8:35 PM

skina, thanks a lot for your great answer. I have nothing to add here.

Jul 18, 2011 at 10:01 PM

skina, I don't disagree with anything you've said except for partially with the very first paragraph. Many patterns are about those exact same things.  They just go about achieving those goals in different ways and to different degrees.  It sounds like you are taking a custom approach ontop of WAF that is more MVVM like if you're not passing views into your viewmodel constructors.

But none of what you said, really answers my original question.  If anything, you've gone out of your way to do some things YOUR way which also happens to be the more WPF MVVM way anyways (at least according to basically everything else I've read so far).

WAF looks like a nice framework, but I completely disagree with it calling itself MVVM on the home page.  Seems like anybody now, as long as they have some class, and they use WPF databinding to get something onto the screen, well, that's all that's required to label themselves MVVM.  I disagree with that. I think there is A LOT more to being MVVM than just using databinding to get something onto the screen.

The whole passing the view, even as interface, into the viewmodel to me flys in the face of every single other mvvm tutorial/sample I've come across.  It's a valid technique used in other patterns, but this WAF is the only one so far where I've seen it done for MVVM.  And it's just confusing.  Now the views are getting back to the viewmodel either via commands or via methods on a view interface.

I wish the people that dream patterns like these up and then others that build "tutorials" actually built more thought out, more useful, more real world sample/tutorials.  Seems like most patterns, as soon as I start to develop, it's very quickly that the most basic of things comes up that's not clearly laid out, and then I research and it's basically confusion on the outside on what is the right way to solve something.

In my case, I'd like to solve the dialog problem but also try to stay within the "spirit" of mvvm. WAF takes the easy,aka IMO shortcut,  way out. Seems like most people for MVVM, rely on a dialogservice and I guess this seems like the approach I will probably have to take as well.

Jul 19, 2011 at 10:18 AM

I share the same frustrations with patterns and tutorials that are only suitable for the most basic use case however I have yet to come across any framework where anything but the most basic use cases are clearly laid out and thoughtfully considered - EntityFramework for example. 

I'm sure I have not yet discovered an WPF MVVM framework that doesn't take any shortcuts or makes use of workarounds. It seems to me that WPF is littered with issues that prevent a complete MVVM implementation - whether that be dialog behaviour or event handling for rich interactions.

In your evaluations of various 'MVVM' frameworks, which one do you feel is most deserving of the title 'WPF MVVM Framework'?

Jul 26, 2011 at 4:50 PM

I've looked into Prism but that is a bit too much for me. I looked at MVVMLight, but that is well, too light. 

Reading up on DialogService now to try and display some viewmodel exceptions messages.

Aug 5, 2011 at 8:45 AM

Recently, I came up with a way of understanding MVVM:

Push as much code as you can to ViewModels. Designers are to design ControlTemplates/styles, not the views. For the views. they are left alone, not testable, not designable. So the views should be kept very tiny and simple.