Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 3 down vote favorite

MVVM pattern is a hot word recently and I am planning to learning and refactor my existing project into this pattern. I have no experience and foresight of the potential risk. Have you guys really get lots of benefit from the MVVM Pattern in real-world projects? Is it worth refactoring an existing non-MVVM (mainly using Code-Behind files) into the MVVM pattern?

share|improve this question
2  
@MattyD - Silverlight's not dead - SL5 is coming out this year and it's the platform for WP7. – ChrisF♦ Jun 27 '11 at 7:48

migrated from stackoverflow.com Jun 27 '11 at 5:19

4 Answers

up vote 4 down vote

I've done 4 silverlight projects and 1 WPF project for customers and all of them were done using the MVVM pattern. So to answer your question if it's widely adopted... yes.

Is it worth refactoring an old project to make use of the MVVM pattern? That depends on the project. Is testability an important factor of the project than without a doubt it is good practice converting the project. If the project is in the begin phase then I would also recommend to make use of the MVVM pattern as it will encourage you to produce cleaner and less coupled code. Is the existing project in an advanced stage and are there other patterns involved then it depends on the budget and time of the project whether it's worth converting it.

Just a little side node of myself. The more I'm making use of MVVM, the more I'm starting to be bothered of the complexity a viewmodel can get and the less I am convinced of whether MVVM is THE way to go in Silverlight / WPF applications. I find it irritating to have my Commands and data properties in the same place because there is no clean sepperation anymore between data and command. For that I would encourage people to also have a look at the MVVMC pattern that solves these issues.

share|improve this answer
but shouldn't the data be in the Model instead of the ViewModel? At least that was my understanding. Else you'd only have View and VieModel – stijn Jun 27 '11 at 6:56
edit I'm not very familiar with this and a quick glance indeed indicates the the VM is violating the SRP. Data is indeed supposed to be in the Model, but the transfer of data to the View is in the VM while at the same time command handling is also in the VM. You happen to have a nice example of using the MVVMC (pff what a name) ? – stijn Jun 27 '11 at 7:04
Yes the data should be in the model but because of the way databinding works in WPF and Silverlight this would mean polluting the model with INotifyPropertyChanged, IDataErrorInfo or others. /* edit yeah MVVMC... whats in a name :P */. I'll try to put a blog post up next week about MVVMC. – Luc Bos Jun 27 '11 at 7:08
I have no problem putting INotifyPropertyChanged and IDataErrorInfo on my Models. I know it isn't the "MVVM-purist" approach, but I find it much quicker and easier to code like that. If this ever becomes a problem, I would probably make my Models into ViewModels of their own, so my properties would still be separated from the Commands and other logic. I'd also rename the original ViewModel something like ProductPageViewModel instead of ProductViewModel, since ProductViewModel would be my Model's ViewModel. – Rachel Jun 27 '11 at 16:12
Yes I see what you mean. The problem is that the act of using a viewmodel as a wrapper for you model so it can propagate changes to it's binding is a violation of soc. Is the viewmodel supposed to interact with the model or is it supposed to expose details to the view? Isn't it best to take the controller out of the viewmodel in this case? – Luc Bos Jun 28 '11 at 6:35
up vote 0 down vote

Yes, this pattern is a dream when building WPF and Silverlight applications. I've used it on many projects, including ones that are public facing production apps and I would use it again if I build another WPF/Silverlight app in the future (I'd even use it in Javascript pages via the knockout.js library).

share|improve this answer
up vote 0 down vote

The single greatest benefit of MVVM is that the complete separation of logic and data from the layout makes it testable. This is often not a concern to stand-along coders, but in the IT industry Test Driven Development (TDD) is now an expected skill.

We also find MVVM "just makes more sense" as code tends to be cleaner and we look at the problems from a broader perspective than the old "just double-click and add yet another handler".

Once you start working on very large projects, I highly recommend also looking at the PRISM framework/guideline as well. It adds yet another level of separation that allows 100's of modules to be developed by separate teams without them tripping over each other all the time.

The only additional thing I will stick my neck out about is: MVVM does not preclude the need for controller classes. We find they make the most sensible place to hang application response logic (not in code-behind, not in the ViewModel and certainly not in the DataModels). Maybe it should be MVCVM? :)

share|improve this answer
up vote 0 down vote

I've found the article with good explanation when you should use the MVVM pattern: http://neverindoubtnet.blogspot.com/2011/05/mvvm-backlash.html

According to the article there is only 3 real benefits of MVVM:

  • design time data
  • automated view testing
  • multiple views over the same view logic

So if your code is clear and satisfactory, your team don't have designers, you don't write unit-tests - there is no point in changing the architecture. MVVM itself has nothing to do with the code quality, it is not a magic wand. But if you start a new project, it can really help you.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.