Paradigm Shift in Web Development to MVC

May 8, 2008 @ 7:13 pm · Filed under Web Design

A few days ago, I started development on the web site portion of one of my new projects. The project is comprised of mobile applications working in tandem with a main web site to deliver a service. However, this post isn’t about the specifics of that project. It’s about a paradigm shift in web development that I have noticed upon returning to the space.

I started development as I always have: prototyping a MySQL database and then constructing PHP pages to flesh out an experience. There would be one PHP script per user facing page, and each would be rife with HTML, include statements, session checks, database queries, display logic, and so on. A library directory would contain includes with common procedures.

Then it hit me: this is exactly how I would have done it five years ago. Web development has changed in that time, and surely I am wiser now. How can I do this better?

The approach I just described is what I refer to as the traditional PHP approach. There may be more official terms, but that’s what I think of it as. Data, presentation, and procedural logic are all intertwined. You write a set of library procedures for manipulating data, all following the create, read, update, delete (CRUD) model, and then call these procedures within PHP/HTML pages for each user facing page.

You usually end up with files like this:

<?php
    require_once('config.inc.php');
?>
<html>
<head>
<title>Search</title>
</head>
<body>
 
<form action="" method="post" name="searchform">
Search <input name="search" type="text"/><br/>
<input name="search_submit" type="submit" value="Search"/>
</form>
 
<?php
 
if (isset($_POST['search']))
{
    require_once(LIB_DIR . '/Db.inc.php');
    require_once(LIB_DIR . '/Search.inc.php');
 
    $db  = DbSingleton(MY_DB_STRING);
    $res = Search($_POST['search'], $db, 'table');
    while (($row = $res->fetchRow()))
    {
        PrintRow($row);
    }
}
 
?>
 
</body>
</html>

This is a simple abstraction for a search page using the traditional approach. An included config file defines the location of the library and a database connection string. There is some HTML for the form and a PHP block for querying the database and displaying results.

As you can see, logic, data, and presentation are all in one file. Think about this for a moment, and you’ll realize that this approach is going to get real ugly, real fast. Without clean separation, it becomes harder to isolate tasks such as web design from tasks such as business logic and data manipulation.

Addressing this problem is the whole point of hot, new frameworks like Ruby on Rails. Rails separates data, presentation, and logic, and it achieves this through the use of the Model-View-Controller (MVC) paradigm.

MVC is a design pattern for structuring applications. How you interpret that pattern is up to you, but in general, the pieces are:

  • Models are objects that abstract away your data.
  • Views are objects that handle the presentation layer.
  • Controllers bridge the gap between models and views with logic based on user input.

In other words, the controller interprets a request, instantiates the appropriate models and gets the data, then it packages the data up and hands it to the requested view for presentation.

MVC makes sense as a good paradigm for developing a web site, and Ruby on Rails is the predominant example. However, that doesn’t mean one should drop their favorite language in favor of Ruby on Rails. I like PHP, and PHP can do the MVC pattern just fine. To that regard, I found 7 reasons I switched back to PHP after 2 years on Rails by Derek Sivers to be enlightening. Here is a quote:

I spent two years trying to make Rails do something it wasn’t meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.

The “Rails-gained wisdom” - the MVC paradigm that I’m talking about - is really what’s important, not the language you do it in. As Derek found out, Rails still has some drawbacks despite all the buzz. You might be better off applying the “Rails-gained wisdom” to a language you are more comfortable with.

If you are a PHP person like me, you don’t have to roll your own framework. The PHP community has joined the MVC bandwagon with projects like Zend Framework, Symfony, and CakePHP.

I recommend trying Rails or one of the PHP frameworks before trying to write your own. People interpret the MVC pattern differently. Trying other frameworks will help you discover which interpretation style works best for you.

I like the Zend Framework the best, and this article pretty much explains my reasons. Plus, it’s sponsored by Zend Technologies, the creators of PHP. Some resources I’ve found helpful are:

This is the extent of my discoveries so far. I hope this post helps someone else thinking of starting a web project. I’ll be using the Zend Framework in my new project, and we’ll see how it goes.

Share This

Leave a Comment

Close
E-mail It