MVVM – Is it Worth the Pain?

I wanted to provide a perspective from "the real world" having worked on several LARGE Silverlight projects and even ones that used code-behind and talked to controls vs. ones that were more traditional MVVM.

Triggering animations - this is straightforward with a delegate that has a callback parameter. The animation can fire and then callback when done, and in testing you can mock your own callback. Typically we just use a visual state transition for this.

I think you struggling with behaviors is hardly a valid reason to condemn them - we use tons of them without issue and from a developers pespective it might be "the behavior is code" but from a designer it's, "I can drag and drop and I'm done."

As for testing, I've worked with several projects that were a nightmare to test because the views had too much logic in the code-behind so the only way to effectively test was to spin up a view and do stuff with it. When refactored to cleanly separate to the view model, the view model unit tests were straightforward and now could be used anywhere regardless of the view.

Data-binding - the point here is that you can build your entire business logic without knowing how the view is implemented. In small projects it might not matter, but for large ones this is huge. I literally just expose a boolean or a string and I'm done - whether the designer implements as TextBlock or TextBox or CheckBox or button doesn't matter to me.

Probably the most important item here is designability. On small projects you're right, probably doesn't matter. On large projects this is key and yes, there ARE designers who write XAML - very good designers. We've built huge Silverlight applications with completely independent developer and designer workflows and they converge nicely because of proper use of the pattern.

Again, I'm not a fan of MVVM just because I choose to be or because I want to make life hard. I've done it with, and without, and we do it faster, better, and have a much better designer/developer workflow when using MVVM.

If you are writing small applications or are the only developer (or one of a few) then I can see where it might not seem valuable, but when you work on larger line of business applications it becomes the key to running a scalable, successful project.

Again, that's not an "here is my opinion because I think it's better" but a fact were encountered based on experience working with MVVM and non-MVVM projects and comparing speed to production, stability, and maintainability of the appplications.

Sure, you can delete the first one. :)

As for the animations ... I'll have to create an example when I get time, but here's the short and long.

1. Attached property (can be a behavior if you like) that gives a story board a "tag" you want to use to for it. This puts the storyboard in a static dictionary with tag/storyboard and wires into the completed
2. On the storyboard completed, an event aggregator message is published with the tag. For example, create a "StoryboardCompleted" message and the value in that message is the tag.

So now you fire the storyboard however you like - a click, a behavior, whatever. The attached property registered it and when the story board finishes, it raises the event aggregator message.

Whatever ViewModel needs to respond simply registers for that message and when it receives it, does what it needs to do.

Does that make sense?

But I guess the question is also - what is the purpose for waiting for it to complete? If it's to chain other animations, I'd use the visual state aggregator instead:

http://csharperimage.jeremylikness.com/2010/03/introducing-visual-state-aggregator.html

If it's to delay an action, for example, I "click" and then an animation happens and THEN I fire a comcmand, I'd use a behavior that simply chains the command to the click. Basically, behavior has three dependency properties: a storyboard (you can bind by {ElementName=storyboardname}), a command, and a commandparameter. When fired, it kicks of the storyboard and waits for completed. When completed, it calls the command.

i sometimes struggle with some points specially things like focus a textbox on the view after something happens on the vm. for that i simply create a event , and subscribe to it in the view. when it's fire i set the focus.

remember that the thing that's improtat is that you should not have conditional code in code behind just strait forward things.


Assumign that you can't have any code on .cs of your view is wrong, if u need it put it there.. just try that is always silpy straight with if or cases or anything like that.

For things liek storyboards i normally use states to contol data, and bind the states to propertys in my VM.. this was trickry at first but after you get the feeling is easy.

I have seen performance recommendations for WP7 that have said that data binding can hurt performance, so I think there are definite instances where MVVM doesn't apply. I write LOB applications myself, not games, and that is where I think MVVM makes the most sense.

One correction though, a ViewModel already is a presenter, MVVM and MVP are synonymous. I think the term you are looking for is Controller.

Another note from the field, MVVM is to me like saving up and paying for something outright versus going on credit and building a lot of technical debt. It's painful at first but over the long term it is more extensible and maintainable.

I will admit that our application is not "testable" or "test driven" in an automated way so this is the smallest factor - we hope to get there one day but at present it's not a factor. It's the maintainability and stability that we like.

With that said, I think MVVM has been victim of too much hype (and consultingware e.g. selling people on a new way to do things that will change their life, but that's another story). People have made it seem like if you aren't using it you're somehow doing things "wrong" even if your application is not data binding heavy or a part of some test heavy process.

I also think it would be nice for Microsoft to push really hard at bringing some of the MVVM functionality right into the main Silverlight SDK. I understand that there's Prism but there's a lot of stuff there for a person simply trying to use some MVVM concepts - I think it's interesting that most people use MVVM Light (e.g. John Papa) because it's so much more focused with less cruft. (We have really enjoyed using MVVM light on my current project).

I've been doing Silverlight for a little while and decided to start with MVVM early on. I knew when I started with Silverlight that I didn't want to make all the mistakes I make with C#, VB, etc. I too love the elegance of it, but it's difficult to get others on-board when I haven't really used simpler methods (like direct text binding). To be honest, despite the fact that testability is big in the industry, I haven't really worked in many places where they didn't see it to be a waste of time.

I like this post because it makes me think of whether I rushed into MVVM or not. But the big selling point for me is dividing the code into manageable areas. The xaml (and code behind) only worries about user-interaction while the viewmodel is concerned with building collections, communicating with the host, etc.

I think the interesting part of your question is whether it's a pain or not for small straight forward applications. I haven't used MVVM but the symptoms you are describing are the same symptoms I had when using the CAB (composite application block) from Enterprise Library.

The amount of things you get solved by these patterns when used in small applications, can sometimes not be worth the restrictions/limitations these patterns impose.

That's why I can totally see Jeremy being happy when using MVVM in LARGE projects.

The only problem I see with using MVVM on large-scale projects is that on the user control level it becomes burdensome to maintain the pattern, which means collapsing the separation between business logic (ViewModel) and UI (View). We've gone back and forth between keeping "control-specific" business logic in the ViewModel and having a lot of repeated code, and putting said logic in the usercontrol itself.

There is also a particular issue with the DataGrid control in Silverlight, in that none of the properties on the DataGridColumns (most importantly, Header and Visibility) can be bound, meaning that the ViewModel has to interact directly with the View if any of these properties need to be dynamic.

Despite these problems, using MVVM with a DI framework makes testability and scalability a breeze. Also, like Jeremy said, we've been able to have a designer work in parallel with development without any conflicts for the most part. Overall I'm happy we chose to use the MVVM pattern on my current project.

We develop most applications in MVVM (although we just stick to plain desktop WPF at the moment) and it works quite well. I think most people are taking the "ViewModel" name to literally. I tend to see the VM more as the glue between the view and the model whereas the VM only has an abstracted knowledge of the view (if any).

Usually the pattern we use is to have a presenter as the datacontext which then exposes the view models for data binding. If the presenter needs to interact with the view then the view becomes an interface which gets passed into the presenter.

So essentially it more like a MVPVM pattern. From experience when you munch around directly with the controls from you view models then it's very likely to go and bite you later (at least it has bitten me everytime I went down that path as quick hack). Just not worth it.

You may like to read Davy Brion's "MVP in Silverlight/WPF Series". http://davybrion.com/blog/2010/08/mvp-in-silverlightwpf-series/

It promotes a greater separation of concerns and therefore maintainability that I think will work better than MVVM, at least for larger projects. I'm going to try on my next one.

MVVM makes code that runs in a single line in Winform as multiple lines of code in multiple files. I think MVC is much better.

I am a Web Developer now working in XAML and MVVM for a Windows App. I work on a very large and robust application with several developers contributing to it daily. While it has been an interesting working curve, I keep finding goodies in MVVM and XAML that amaze me. For example, I was easily able to bring in a JSON API the other day with minimal effort. The longest part of the process that was just learning how to do it. Once the data is parsed it almost naturally flows into the application and can be easily customized to fit your needs. I am not sure if we could even create such a robust application without MVVM, for what we are doing. I hope that people continue to use MVVM and XAML for other applications going into the 2020s.