Chapter 1: Welcome to the MVC World
6
Because of MVC ’ s three - part separation, developers can create multiple views and controllers for any
given model without forcing changes in the model design. This separation allows for easily maintained,
portable, and organized applications that are nothing like anything you ’ ve worked with before.
For example, imagine that most prototypical of early 21st century web applications, the blog. Blogs are
everywhere these days, and they ’ re not that hard to break into their constituent MVC parts:
A model that keeps track of posts and comments
Multiple views that display individual blog posts, a list of blog posts, or search results
A controller that captures user interaction (such as clicking on an archive link) and then redirects
requests to models and/or views
Drilling down further, an MVC blog application might involve the following flow of events:
- The user visits the blog home page.
- This simple event requires a controller action for the home page, which makes a quick call to the
model to retrieve the last 10 blog posts in reverse chronological order. - The model ’ s data are then transmitted to the view for the home page.
- The view (including the data retrieved by the model) is what the user sees in his or her browser.
- The user clicks on a link to see details on a particular blog post.
- The underlying controller captures this user input (clicking the link), uses the model to retrieve
the blog post in question from the database, and then loads the appropriate view. - The cycle begins anew when the user clicks a link to view comments or runs a search.
Another way of thinking about this breakdown of roles is to map it out this way:
User Input and Traffic Control = Controller
Processing = Model
Output = View
This three - part analogy is a much simpler way of looking at things. Some might argue that the approach
is much too simple. After all, it ’ s possible, some might argue, to create an MVC application without a
model, or to gang - press view code into the controller. It ’ s not a good idea, but it can be done. For right
now, this simple analogy holds. Different ways to approach problems in an MVC fashion are explored
later in the book.
Why Bother with MVC?
Although at first glance the MVC approach seems like a lot of work, it really isn ’ t. When developers of the
hypothetical MVC blog application want to change something about the home page, they ask themselves
about the nature of the change. Doing so allows them to zero in on the part of the application they need to
work on.