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.
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.