Podcast:: Design Patterns Bootcamp: Model View * Patterns
Design Patterns Bootcamp: Model View * Patterns
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
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
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