As a part of his "Advancing PHP Developer" series, Eran Galperin has posted part five, a look at design patterns and what they can do for you and your application.

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.

Bill Karwin (formerly of Zend and the Zend Framework project) has a new post to his blog defending one of the more abused (both in code and in opinions) design patterns, ActiveRecord:

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.

Michael is back with part three of his series stepping you through the creation of your own MVC framework (Part 1 and Part 2) with a look at the part that interfaces with the user - the View.

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.

In this new post to his blog today, Padraic Brady continues his series looking at developing a blog with the Zend Framework. He moves on to look at the MVC structure behind the application in this latest post.

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.

Michael Girouard has posted his 10,00 foot view of the typical structure of an Model/View/Controller application (and framework) and how a page request is handled:

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.

Pádraic Brady has a suggestion for all of the PHP readers out there - two articles in the latest edition of php|architect magazine, the May 2007 edition:

The two that stick in my mind are Jim Delahunt's "Unicode and PHP: A Gentle Introduction" and Jeff Moore's "Test Pattern: Model View Controller". Both are something those seeking illumination on these topics should certainly read.

The first presents an introduction to one of the hottest topics in the PHP world - Unicoding - including a few same scripts to get you going. The second article, a look at the Model/View/Controller pattern that really gets more to what the pattern is about rather than just talking about its structure.

Joseph Crawford in looking for a PHP framework to work with at his job, decided to give CodeIgniter and liked what he saw.

Since I have started at my new job we have been looking into several different PHP frameworks to use for the new development. We pondered doing a custom framework for the site but in the end we opted to go with CodeIgniter. I have to say that overall CodeIgniter is a really nice framework. It saves us a lot of time and code when we want to do simplistic things. The best part about CodeIgniter is that it is based on the MVC design pattern.

He gives an example of one way he's using the framework a Controller that loads in a custom library and uses it (to send an email). There's also a bit on how his application is set up - directory structure, using mod_rewrite, and even some issues that he's come across so far.

In a today, Chris Hartjes talks about fat models and skinny controllers:

He includes an example of this school of thought - an update to a previous project that shows most of the functionality and logic (schedule information being pulled in and parsed) and the controller that, lightly, grabs this information from the controller and, blissfully ignorant, passes it right along to the view to be displayed.

phpaddiction has posted part three of its URL Rewriting tutorial series today - the creation of the "C" (Controller) in MVC.

In the final part of this series, I will build a functional modular front controller that can be easily adapted to small projects. It is basically the "C" in MVC for a simple MVC framework. If you haven't read the first two articles I recommend that you read over them first. Url Routing with PHP - Part One and Url Routing with PHP - Part Two.

They start with the base created before (with some slight modifications) and build up the dispatcher to handle their new requests and the controller to respond. In their example, when the Controller is called, it runs the execute() method and, based on the input, either calls another function or returns an error if it doesn't exist.

Tony Bibbs has announecd the latest release of a framework he's developed to make MVC in PHP applications simple - MVCnPHP.

It's been a long while since the last stable release but I'm happy to announce the release of MVCnPHP v4.0.0. This release has been a long time coming as it brings a configure-less controller. Just drop your views and commands into the directories you configured the controller to use and it will monitor them for changes.

Upon finding a file that has changed it will pull the MVC metadata out and add it to an internal configuration array that the controller will happily load into memory using APC or write out to a .php file. This basically catches this MVC implementation to what's been available in Ruby on Rails.

Also included is some sample code to get you started as well as a direct link to the PEAR channel where the framework can be downloaded.