Model-View-Controller (MVC) is probably one of the most quoted patterns in the web programming world in recent years. Anyone currently working in anything related to web application development will have heard or read the acronym hundreds of times. Today, we''ll clarify what MVC means, and why it has become so popular.

The look at each part of the MVC stack including what it's for and how it connects with the other two parts. An example is included - not in code but with an image showing the communication between the modules. They wrap up the post with a look at why using a MVC framework can help you be more productive. Their example uses CakePHP but the ideas could be applied to any MVC framework out there.

In reality, implementing this view-centric method is actually pretty easy to achieve. However, CodeIgniter provides web developers with enough flexibility to handle views in all sort of clever ways. Therefore, in this series of articles I'll be discussing in detail some common approaches that you can use to generate views, ranging from loading them sequentially, to using more complex methods, such as including views within other views.

They introduce you to the view system CodeIgniter offers and show you how to create a basic view as a part of a controller class that displays a page with a header, user content and a footer.

Today's rant is about the Smarty templating system for PHP. A recent blog post by Paul M. Jones has rekindled my strong feelings against Smarty. Honestly its nothing personal. Its just I can't believe developers are still using Smarty or that they ever started using it. Unthinkable.

Quinton talks about when he first discovered patterns and N-tier including the Model-View-Controller pattern. This naturally lead to needing a templating engine for the views, but from everything he could tell about Smarty it "solved the wrong problem" (he chose phpsavant instead). He even points out an author who, despite writing a book on Smarty, still came back and said that there's no need to use something like that in an application.

"What is a model" and "Is Zend_Db_Table a model" seem to be asked once in a while on #zftalk. Frameworks say they have a full model available, thus they are MVC frameworks ORM libraries say they generate models. It seems the ActiveRecord pattern has become somewhat synonymous with model.

He points to a post from Padraic Brady on the subject and talks about how one might put it into practice. He admits to making a controller action just to get data from the database into a view, but offers a "more correct" alternative - a view helpers that creates a model instance your view scripts can use directly without the controller in between.

By the time I'd finished both chapters [of my Zend Framework book] I realised I had spent a lot of space explaining the Model, most of it discussing how the Zend Framework does not actually give you one. In fact, no web application framework offers a complete Model (for reasons I'll explain later). However nearly all frameworks manage to avoid making that perfectly obvious. Instead they continually link the concept of a Model to the related, but not identical, concept of data access. This is quite misleading.

He looks at two things models are good for (maintaining state and enforcing rules on the data in the current state), how it seems most PHP developers perceive them, how controllers can be turned into "mutated models" and the idea that models should be classes and controllers are just processes (handlers for requests).

A design pattern is a general reusable solution to a recurring design problem in object-oriented systems. Design patterns are essentially blueprints that suggest how to solve a particular set of OO design problems while adhering to OO best good-practices (which I've recounted in my Object Oriented part of this series).

He talks about one of the most popular examples - the Model/View/Controller design pattern that is used in many rapid development frameworks for PHP (including CodeIgniter and the Zend Framework). He also briefly mentions a few others like the composite, singleton and decorator patterns.

Other parts of this series include looks at testing, refactoring and coding standards.

ActiveRecord is fine. It is a tool that does just what it's designed to do. What sucks is when developers try to make it do other things than what it's intended to do.

He cites his work with the Zend_Db component and how Mike Seth gets it right when he says that the pattern shouldn't be "ActiveRecord-View-Controller". He compares the ideas of a true Model in an MVC application with the incorrect ideas that many developers seem to hold.

A Model is a class that provides a logical component of your application domain. Models are products of OO design, which is a development activity I see get very little attention in the developer blogosphere or the developer tools market.

Models can reference one or many (or no) database tables and are not where the hard work is being done. That's saved for the ORM (or ActiveRecord) to do.

Using the view as a starting point may seem odd at first considering the view-related actions are some of the last steps in the page load scenario, but since our views don't have any external dependencies, unit tests are very easy to write and so is the accompanying code.

He explains how views work along with the rest of the framework and some of the basic rules surrounding how they get their data. Code comes along with the explanations for different views like XML, HTML and JSON methods of output.

After speaking with any number of users about getting started with a framework, I find many do not have an advanced understanding of the corner stone of a current day web application framework: the Model-View-Controller Design Pattern.

He explains the normal development approach (kind of a Page Controller where each bit of functionality has its own page) versus the Model/View/Controller approach of separation of presentation and logic in a structured fashion. He also goes through each of the parts of the MVC equation and shows the difference between the roles that the Controller and Model have in the application.

In my previous article, I announced that I would be documenting the process of developing a simple MVC framework. In this post I will go into a little more detail about each of the specific components of our MVC and will discuss the series of events which occur each time a page loads, otherwise known as the page load scenario.

He talks about how URIs work, the role of mod_rewrite, several of the objects involved (like the Front Controller, Request, Route and View) and how they all fit in with the custom Models, Views and Controllers the user could define.