Learning WPF and MVVM

Question

Hi folks

I have recently joined a new developing project building a thick client application using WPF and MVVM. I have developed applications in various .NET frameworks from 1.1 through to 3.5 and all major technologies; WebForms, MVC and WinForms. On all of my projects I have enjoyed every minute of it but on this project I feel that I am struggling and as such not enjoying it as much. When .NET 3.5 came out in 2008 I really enjoyed learning the new language features (LINQ, MVC, Lambda Expressions, etc) and dabbled in WPF so please don't assume I'm against learning something new.

But the learning curve on this project seems really steep and I feel that learning MVVM on top of WPF + the application is a little daunting. Although I have only been on the project for a short time (2 weeks) I really like WPF but have taken a disliking to the MVVM pattern. My disliking to the MVVM pattern may because I don’t really understand it and I feel that I have to write a lot of “non best practice” code in order to do what was relatively simple in my WinForms days.

So my question is has anyone else faced a similar situation and did you stick with MVVM or go in another architectural direction?

Answer 1

I started learning WPF and quickly came across MVVM - it seemed like such a good fit that I've stuck with it. It's probably worth pointing out that there do seem to be some differences in the ways people implement MVVM, a key one being View-first or ViewModel-first. Some seem to see this as a point of gospel - I don't have enough experience to decide if it should be. I tend towards View-first (so View has a reference to ViewModel and ViewModel has a reference to Model and none in the other direction) but I have come across a scenario where the other way was easier.

Why not post some questions around the specific points you see as non-best-practice. It might help others wrestling with this subject as well.

One other question: are you using a specific framework for MVVM?

Answer 2

Well, before using MVVM, I used MVC in ASP.NET MVC framework. The Model-view-controller architecture is pretty obvious there so it helped me to change my attitude from standard ASP.NET and WinForms.

MVVM is a little bit "harder" to understand, but once you realise that WPF differs from web (you as a user respond back to the view, not to the controller), it makes sense to move from MVC to MVVM. I suggest reading articles about MVVM on homepage of Caliburn project (left column, part 3. Study in MVVM) - this helped me a lot.

Regarding WPF (Silverlight) applications, I would strongly recommend to start building applications right on top of PRISM (Composite WPF) and/or Caliburn - although it might be confusing from the beginning, still it is a much better choice than with vanilla WPF (speaking about practices they force you to use). But take it for sure that once you have finished your first WPF application, you will want to rewrite it from scratch. But that's how it works when you learn a new technology.

Answer 3

I have been working with WPF since the beta versions and I would never go back to winforms. To me MVVM is a philosophy and it takes a lot of work and discipline to implement it faithfully. It encourages complete decoupling between UI and interaction logic which means no code behind whatsoever which means testable interaction logic which is very difficult to do with winforms.

In contrast to gius I would recommend you stick with plain WPF and MVVM especially if you are just starting out with WPF. There is a lot to grasp with MVVM and WPF, adding to that will just slow down your progress. But that's just my opinion. I always prefer to layer my learning rather than try to learn everything at once that way you are in control and you have more knowledge about how your application works.

If you have not already done so I strongly recommend you read the MS article on MVVM :

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Its fantastic and it is compulsory reading for my team members who write any WPF code.

I am not sure how you and your team work but you need to ask yourselves whether or not MVVM is for you. If unit testing / test driven and decoupled UI is something you are already doing or is important to you then MVVM is definitely a good path to take. If your team is happy with writing code behind and you don't see why you should bother decoupling then don't bother with MVVM as you will find that it will slow you down. Personally the latter is never an option for me.

Please feel free to contact me if you have any specific questions about WPF or MVVM.

Answer 4

MVVM is just a design pattern. You do not need it unless you are comfortable with WPF. If you are learning WPF, I suggest you first complete the book, then learn about MVVM. If you try learning both, you would try to implement MVVM in every simple WPF app or do not understand some feature of WPF that MVVM uses.

P.S: I came to this conclusion when I faced the problem myself. I still do not understand how the ViewModel can create a new View if it knows nothing about it.

Answer 5

I have faced a similar situation, and the route I decided to go was:

• Use ViewModels for my views, but avoid some MVVM pureness, like Attached Behaviors (which I find dumb and clunky)
• Use Magellan MVC framework, which fit best my mental model about how an applications should behave.