Design Patterns Bootcamp: Model View * Patterns

Audio

Introduction to Model View * Patterns: | download
Model View * Patterns - FAQ and Video Review: | download

Video

To play downloaded files you will need to install the Swiff Player.

Part 1 - Implementing Model View Presenter using Supervising Controller
Part 2 - Using WinForms (VB.NET)
Part 3 - User Messages
Part 4 - Data sources, using a service layer and maintaining state
Part 5 - Encapsulating DropDownList Data Sources

Thanks to Dave Bost for the intro!

What is the Purpose of These Patterns?

Put code in its proper place
Way to provide clean reuse of the domain model
Way to increase testablity

Rocky Lhotka wrote a blog post about a year ago that discusses where validation logic should live in an application. The entire post is great, but by the end of the post he make a point that reaches beyond the question of where validation should live... " There's nothing more expensive than a line of code in the UI - because you _know_ it has a half-life of about 1-2 years. Everyone is rewriting their ASP.NET 1.0 UI code to ASP.NET 2.0. Everyone is tweaking their Windows Forms 1.0 code for 2.0. And all of it is junk when WinFX comes out, since WPF is intended to replace both Windows and Web UI development in most cases. Thus code in the UI is expensive, because you'll need to rewrite it in less than 2 years in most cases."

Model View * Patterns... What are they?

The main drawback to these patterns is usually the learning curve... this show will hopefully remove that barrier-to-entry. The first on the scene and primary pattern to all each involved is the Model View Controller. This pattern is used throughout many of the modern development platforms. The quickest way to describe MVC in the terms a .NET developer will understand is that you code your pages in such a way that you place the code that would be in your code-behind, into a separate class. This class is called a "controller". The "model" are your domain objects (business objects or data access objects).

So your controller will tell your domain objects what to do. Once the work is done, then the user interface must be updated. The code in the user interface is known as the "view". So if you can picture that the code-behind in an ASPX file is no longer where you do any real work and can re-label that code the "view", and you can picture a new class that would act as a bucket for the code you would have written in your code behind to do the work (call that the "controller") and imagine the finaly peice of the puzzle as a class that talks to the database, to encapsulates some business logic or does something else completely unlreated to any user interace (and call that the "model"), then you, my friend have just understood the most difficult part of the Model View * patterns.

What's built into ASP.NET?

Some people say that ASP.NET has the MVC pattern implicitly implemented in the web forms architecture. The thinking goes like this... the ASPX markup constitues the view, the code behind plays the role of the controller and domain objects represent the model. While this seems to fit nicely into the formal definition of MVC you quickly run into problems.

Michael Hamrah makes the point that ASP.NET declarative controls don't break pattern, just limit your flexibility.