Podcast:: Design Patterns Bootcamp: Model View * Patterns

Published 08 March 07 08:11 AM

Design Patterns Bootcamp: Model View * Patterns

Listen to the Show!

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.

What is the Difference Between MVC and MVP?

  • in MVC view talks to Model
  • in MVP view can know about model, but won't send message

How is MVP Constructed?

Model View Presenter comes in two flavors:Supervising Controller and Passive View

Make sure to check out the MVP stub generator!

  • Supervising controller will has some logic in UI, such as databindingd, etc.
  • Passive view will have NO logic in UI
  • Supervising controller is less complex and less-testable
  • Passive view is more complex and more testable
kick it on DotNetKicks.com

Resources

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# John Kuhn said on March 12, 2007 6:27 PM:
I know I've brought this up before, but I'm still not convinced. Why wouldn't you simply pass an instance of IView<> to a method of the business layer?
# polymorphicpodcast said on March 13, 2007 12:42 AM:

Doh!  This is a great question and I meant to discuss this in the show...

There are a couple of reasons I wouldn't recommend going this route. The first reason is that often a feature that you are implementing is more complex and talks to more entity objects (or data classes) than a single object. So coupling an implementation of a database IO feature that spans the use of many features isn't a desirable option.

The next reason is that your business objects shouldn't know anything about the user interface. A Presenter object will often deal with events that will clear the view, pass messages up to the user interface telling what state error or status messages should be, etc. So baking this information into your business object couples your business layer to the user interface in ways that you probably don't want.

Craig

# podcast directory said on June 7, 2008 12:26 PM:

Well said

Leave a Comment

(required) 
(optional)
(required) 
Enter the code you see below