WPF + MVVM, etc.

Actually, it looks like Amazon sells one book that has both WPF and MVVM in the title but this book has pretty bad reviews, so at this point I'm looking for people's opinions on the best / most helpful WPF book period and I'll just have to figure out MVVM from the internet plus reading the codebase I'm working with ...

Being an old guy my natural inclination would be to buy Charles Petzold's "Applications = MarkUp + Code" (or whatever it is called) because it's about windows programming and is written by Charles Petzold; however, this book looks a little a dated to me -- also it has some bad reviews. So, you know, should I get the O'Reilley book or what?

Anybody?

MVVM is super simple, just don't get a book. A viewmodel is a model abstraction (state and contract), but, like, for your view. Google for concrete examples, or if unsure I'll give a more detailed example when at computer.

When I started with WPF, I felt like running up against a wall. After grew a bit more comfortable with WPF and began using it like one would WinForms.

What finally opened my eyes to how silly and time wasting this style of writing GUI code is was when I worked my way through Microsoft's MCTS 70-511 self-study kit. After I understood some details, such as WPF's retained mode GUI tree through which events bubble up in the hierarchy and got a good grasp of its excellent data binding stuff, MVVM was a no-brainer.

I think the key to MVVM is the data binding part. I.e. this: In WinForms, if you want to have a list with differently colored cells, you fill the list and assign a color to each cell. In WPF, you would instead data bind the list and attach a data trigger to the list that determines the color a cell should have. In other words, don't assign things to WPF controls, provide them in your view model and let the view consume them.

There are numerous MVVM frameworks for .NET. Caliburn Micro is popular, but I wouldn't recommend to start with it as the job it probably does best is confuse new developers. Try MVVM Light (they have a few good 10 minute introductions and videos, too).

Regarding MEF, you're half-way there if you understand IoC containers. Microsoft's own, semi-official IoC container is Unity, my favorite one is Ninject - because I think its design is more expressive than all the others.

IoC is a perfect companion to MVVM because you can just ask the IoC container to construct a view model and the IoC container will automatically provide the services the view model wants to consume.

MEF is basically just an IoC container specialized to support plugin design patterns. For example, you could write a class with a constructor that takes a list of [font=courier new,courier,monospace]IThingy[/font], then ask MEF to create an instance of that class for you. MEF will automatically search all exported implementations of the [font=courier new,courier,monospace]IThingy[/font] interface and construct your class with a list of them.

MEF is part of .NET 4.0, so it's often used instead of a specialized IoC container. This is what I would suspect is the case in your project.

I think the key to MVVM is the data binding part. I.e. this: In WinForms, if you want to have a list with differently colored cells, you fill the list and assign a color to each cell. In WPF, you would instead data bind the list and attach a data trigger to the list that determines the color a cell should have. In other words, don't assign things to WPF controls, provide them in your view model and let the view consume them.

Yeah, after spending some time with this code I think the main thing that was confusing me is that the way that it is establishing data bindings is non-standard relative to the various MVVM tutorials and examples I've seen online. Basically, in sample MVVM code you see data bindings being declared in the XAML like the following: or whatever. However, the codebase that I'm working with doesn't use any markup like this. It creates bindings dynamically by using reflection on the view model object and seeing if the view model has any properties or methods that have the same name as gui objects in the view then creating bindings with code based on the type of the gui object.

Anyway, there's still a lot I don't understand but after figuring out the above it no longer seems that the GUI works by magic so I'm in a much better situation...