WPF MVVM – Is MVVM the Right Choice for Single-Developer Projects?

Is there any easy step-by-step reference to MVVM?

Yes, there is. Take a look at the here.

Is MVVM a super-set or a sub-set of MVC?

MVVM belongs to the MVC family, so, if you can say that at all, it's a subset. It's a variant to decouple the UI from the business logic underneath. I'd describe it as a sibling of MVC. Since the early days of OOP people have been searching for ways to decouple the UI from their logic. MVC was the first archetype that evolved. It is pretty simple, although most people do not get it right. The view is just an observer to the model and calls it when necessary. The controller is just a strategy for the view to communicate with the model, for example when you need an exchangeable behaviour (i.e. ReadonlyController, AdminController). MVC is very successfull and it's really a good practice to apply it.

MVVM is a specialized kind of MVP Pattern, as described by Martin Fowler. MVP tries to keep the view as dumb as possible (while still taking user input etc.), thus enhancing the testability. It aims for an abstraction of the view and the interaction-logic which is to put in the presenter. The presenter solely communicates with the model/business logic and updates the View. Martin Fowler describes MVVM pretty much in his Presentation Model Pattern.

The view is completely abstracted into a ViewModel. When the View needs a property, the ViewModel needs to have it as well. It (the ViewModel) is meant to be completely independent of underlying UI-technology, an abstraction. In order to communicate between View and ViewModel, a synchronization pattern needs to be used (i.e. Observer). This is not easy to accomplish in a stateless web environment. MVVM differs from MVP, as the View does not bind to your model/business logic anymore but to a ViewModel instead.

Which pattern is modern and which one should I choose for Windows & Web versions of my application?

Presentation Model (MVVM-like) in theory should be completely independent of the UI-technology in use. However, the synchonization aspect needs to be covered. It can easily be done by binding to Commands and Properties with WPF, where the synchronization glue is already present. With ASP.NET, this is a different story. However, there's an article on CodeProject which used Presentation Model Pattern with all Windows UI technologies. Have a look.

My perspective is from years of experience working with Winforms, the "old fashioned way," with events and code-behind. So I can tell you with absolute certainty that, once you get beyond the simplest of applications, your code quickly becomes a big ball of mud. It was inevitable, because that's the way applications were written back then.

Webforms is just the same, except that it throws in the additional complication of being a stateful abstraction over a stateless system (the web). As Rob Conery put it:

WebForms is a lie. It’s abstraction wrapped in deception covered in lie sauce presented on a plate full of diversion and sleight of hand. Nothing you do with Webforms has anything to do with the web – you let it do the work for you.

This, from the guy that wrote a fully functional object-relational mapper using the dynamic keyword in C# and only four hundred lines of code. When he speaks authoritatively about something, I listen.

The application I'm currently working on is a Winforms application, with several tabs in the main form. I can dynamically load forms into each of the tabs. While I didn't follow MVVM or MVP (you can, with libraries like this one), I did aggressively push every bit of code I could out to a separate assembly, leaving only that code that is absolutely required to run the form. There's still several hundred lines of code in there, not counting the partial class containing the form's control definitions, properties and event handler assignments, but I should never have to touch it again, unless I need to add something new to the form.

I have a static method that I can hand a form and a collections of Key/Value pairs, and it will (using Reflection) automatically match up the keys to the fields in the form, and populate the form with the collection's values. I can also do the reverse, getting a collection of Key/Value pairs from the form's fields. That whole thing is about twenty lines of code, but it pays for itself every time I use it, because I don't have to write forty custom assignment statements for forty controls on a form.

I can take that Key/Value list, and serialize it to XML, allowing me to persist it to a file. I have other forms that I can hand a conventional DTO, and map its fields to the form. None of this would be practical in the "big ball of mud" style of Winforms. It's almost trivial when adequate decoupling is utilized.

Does any of this sound familiar? It should; it's essentially a poor-man's form of data binding.

Admittedly, I really like the databinding of WPF. To take advantage of it, I set the data context to the window itself, where it has access to the business class as well as any other observable properties.

Good for you. It doesn't have to be MVVM compliant. But remember, patterns like MVVM were created to help developers build big systems. If you just need to display a dialog, you may not need all of that plumbing.

Part of the complexity of systems like WPF is inherent in all programmer libraries that seek to solve a specific problem in a generalized way. To do that, you have to account for every practical way a programmer might use your library. That adds complexity, but for those who design their libraries well, it also brings to the table a philosophy of doing things in a uniform and consistent way.

Consider John Resig's jQuery library: it is the very essence of a coherent design, and it hides a lot of weird details about the DOM, and variations in the way browsers handle it. Is it simpler just to write a few lines of Javascript? Sometimes. But the benefit of writing jQuery code in a coherent, uniform API makes it easier for the next person who comes along to understand what you did, and maintain that code if needed.

My real experience with "big application" models is in using ASP.NET MVC. ASP.NET is to ASP.NET MVC as Winforms is to WPF. When I worked in ASP.NET, I always struggled to bend it to my will. ASP.NET MVC bends to you. It is a joy to use; it produces a system structure that is clear and organized, and gives you full control over your application and markup. You can use Javascript, jQuery and CSS liberally, and ASP.NET MVC stays out of your way.

My only hurdle was getting used to it, and getting to know it on its own terms.

Further Reading
You Should Learn MVC by Rob Conery