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?
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.
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.
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? :)