Another Thursday, another fun Virtual Brown Bag. JB shared some more Rails/Heroku love today, and how he’s implemented the registration/login feature of http://www.virtualbrownbag.com. The more I hear and see things about Rails/Heroku, the more I like it. I need to find me some time to start messing with those things.

We had a special request from Mark, one of our frequent VBBers: he wanted to see a little example of MVVM, and maybe have a little talk on MVC.

I showed a very simplistic sample of a WPF app, where we started with having most of the code in a code-behind for a window, and then moving the code out into a ViewModel. We’ve covered the core differences between MVC (Model-View-Controller), MVP (Model-View-Presenter), and MVVM (Model-View-ViewModel, or also known as Presentation Model). The idea bein  g that they’re all “presentation patterns”, aimed to better structure the code that sits closer to the User Interface.

So why so many different patterns just for that? Well, each one has a slight different structure to cater for the scenario have at hand. In MVP, the Presenter takes care of providing behavior to the View. The View does nothing more than delegating things to the Presenter. This allows the Presenter to be reused independently of the View, and it’s also testable.

In MVVM, the ViewModel gives shape to the data coming from the Model, tailoring it to the View needs. For instance, the Model may have separate properties for Address, City, State, whereas the View calls for just a single property representing the Full Address; the ViewModel will handle just massaging of the data. ViewModels fit in nicely with WPF/Silverlight due to their data binding features.

In MVC, the Controller is usually the one responsible for executing behavior, and in web applications the Controller is usually the point of entry for the user to execute operations: when the user either enters a URL in the browser directly, or clicks something on the page that sends a request to the server, there’s a Controller intercepts the call and takes the appropriate action.

ViewModels are commonly used in MVC applications as well, but different than in WPF/Silverlight applications, they only provide the “data reshaping” aspect of it.

Even on a MVVM WPF/Silverlight application you may find “Controllers”, usually helping out with the way the application flows through menus and screens.

MVP is usually the best bet for WinForms and WebForms applications. So why not use MVVM in a WinForms application? Because MVVM leverages the WPF/Silverlight data binding capabilities, which in WinForms aren’t that great.

As with all design patterns, there isn’t one presentation pattern that’s the silver bullet to all applications. Depending on context, requirements, etc., a single application may mix and match these patterns: have a Login screen implemented using MVP, whereas an order placement screen may be implemented using MVVP, whereas a more complex composite screen may be using MVVM with a Controller added to handle the flow between the different parts of the screen.

This post isn’t supposed to be nothing more than a brain dump as to what we’ve discussed at the Virtual Brown Bag this week. Please make sure to take the time and go do some research and experimentation on your own.