Do I really need MVVM for this?

Question

Not too long ago I started writing a docking library for WPF (similar to Avalon). At the time my goal was to do it the MVVM way just for learning. To have things running, I decided to first design the view and model parts and thought I'd throw in some view models in between at a later time. Now I'm done with all the view and model stuff: views get a model and talk to it directly, while models expose a series of events to blindly notify their listeners. Also, every visual aspect of it can be restyled/templated in XAML. Things are working just fine. Now I'm stuck at the view model part.

By the nature of this kind of library (contents change and are recreated dynamically), there's a lot of code that has still to be written in the code-behind part of the view, and I don't really see a benefit in having to also write a bunch of view model classes for every view. Probably it'd come handy to use some binding/commanding in a couple of places, but I don't really think it makes up for all the refactoring needed to accomplish a pure MVVM design.

I do understand the advantages of the MVVM design and I like it a lot, but in this very case I fail to see how view models would add any value to the whole thing.

Any ideas, suggestions or corrections would be much appreciated.

Thanks in advance.

Answer 1

The way I always understood it your Model is just data, and thats it. No methods or anything like that (I dont even implement INPC in my models)

The purpose of your view model is to present the data to your View in a friendly way. So you should never bind directly to model data, always bind to data on your View Model.

What I do is have my Model, lets say the model is a class of Person, It would just hold the values and nothing more, If I wanted to use this class to bind to then I would create an instance of it on my model. If however it needed INotifyPropertyChanged I would create a DVM (Data View Model) this contains an instance of the Person class and has properties to get / set the data in the person class, but also raises INPC when needed. This class would also contain any UI Specific data which I may need.

So my implementation of MVVM looks like

Model > DVM(optional) > ViewModel > View

The view never talks to the model directly, only via the viewModel.

I also feel that Code behind should be kept out of a good MVVM implementation as much as possible.

In answer to your question is MVVM needed? Probably not BUT done well I find an MVVM application very easy to understand and maintain.

I think your problem with MVVM here might have just been the way you approached the design. I always create my empty view model classes at the same time I create the view, this way it doesnt seem to be such a big task.

Answer 2

Part of the problem here is that you're effectively making a control library - and, as such, you're developing something that's entirely part of the "View" in MVVM. While you can probably force an MVVM-ish "model" into place around this, it will potentially muddy up your code.

Remember, MVVM was intended to bridge application specific logic and data to a View - but in this case, your "logic and data" is the View itself, as you're writing a control library. Separating the View from the Model doesn't make as much sense here - since the Model is really part of the View already.

I'm not suggesting that having clean separation of concerns is not valuable, but thinking of this in terms of MVVM may be less than appropriate, in this case. The Model is not separate from the View, and trying to completely separate it and add another layer of abstraction in between may be adding complexity without gain.

If you're making a custom control library, the goal shouldn't be to write it using MVVM, but rather to make sure that your control works cleaning when used in an MVVM application. This typically means making sure your control(s) all expose proper Dependency Properties for all content and settings, and that they work cleanly with data binding, etc. In fact, events are typically not required, at least not as much, and having a separate "model class" hierarchy will get in the way of your users - users expect to be able to drop your control in and bind to properties directly on that control, which pretty much guarantees that your control will have code behind.

Its a fallacy to automatically assume that MVVM is appropriate just because you're working with WPF or Silverlight. MVVM is appropriate for certain types of applications, but a control (or control library) is not necessarily one of them.

Answer 3

If you have a lot of code in code behind - you are not using MVVM in the right way, most things could be done in MVVM way - implemented either in View or ViewModel by using Bindings or Commands.

I fail to see how view models would add any value to the whole thing.

ViewModel provides:

• Model itself, very often ViewModel encapsulates model itself (when no needs to substitute different models in the same ViewModel)
• Data exposed by an udnerlying model (because ViewModel bound to View's DataContext, not amodel itself)
• Command handling logic
• Flags which simplify life for View - for instance expose flag like bool IsValid so View can render green background instead of Red (simplified to show logic encapsulation and delegation of responsibilities)

Answer 4

The way I see it, the View Model is intended to extend your model to cater to your UI without having you ugly up your model with a bunch of UI-specific code. If your model is by definition an object designed to be used for UI construction, then it really satisfies the roles of both model and view model, and there's no point adding another layer to the design.