MVVM or MVC? Want to use the same set of classes for WPF and ASP.NET

Question

I am a newbie in terms of Design Patterns. I just started learning MVC when I am hearing a new buzz, MVVM.

I want to learn the insights of both of these by redesigning an old inventory and invoicing application I developed for a client. I want to write both a Windows based WPF application and a Web based version. I want to use the same set of classes if possible, if not, then at least with little modification.

I read a couple of articles, but I am not following the architecture and the high-level concepts of .NET 3.5 & 4 discussed there. I want to move step-by-step by designing only what I really need in my real-life project.

Is there any easy step-by-step reference to MVVM? Is MVVM a super-set or a sub-set of MVC? Which pattern is modern and which one should I choose for Windows & Web versions of my application?

There are certain classes which I rarely need to connect with the View. In that case, designing the same class in the MVVM way will prove to be an added labor.

Answer 1

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.

Answer 2

Due to lifecycle issues and the need to keep state between page posts, you will find it very hard to reuse 100% of your none UI code between web and WPF. Asp.net does not have the powerful data binding that is needed for MVVM, also a lot of the logic needs to run in jscript these days as people expect the UI to update its self without the need for a postback.

If you could use SilverLight your life would be a lot less complex :-)

Likewise can you host a web-browser in your WPF app for the common bits of UI?

Answer 3

Your intention to use the same classes for ASP.Net and WPF based UI is not very practical. The databinding and the use of javascript on the web is very different to WPF. The only option I can think of is MVP with completely passive view. In theory you can have the same presenter that populates a Web and WPF page.
In practice I will develop an architecture where most of the business rules is in a web service layer and two different presentation tier with as little business rules as possible that talks with this web service.