On the Zend Developer Zone today there's a new post from Keith Casey about some of the design patterns he hates - ones that are misused too often and have become more of a "worst practice" at times than others.

To be clear, I think Design Patterns have their place. When used properly, they can make our lives easier and our code better. When they're misused - "If the only tool you have is a hammer.." - then they can become the bane of our existence. Unfortunately, some Design Patterns seem more susceptible to this than others. So maybe this is less "design patterns I hate" and more of "design patterns that have been abused beyond all sense of reason"... I'll let you decide.

He has three of the most commonly misused design patterns in his list. Anyone who has looked into using patterns in their applications will recognize them:

• Active Record
• Factory
• Singleton

For each, he describes some of the bad implementations he's seen and notes that, while these are commonly abused, they can still be redeemed by being used appropriately.

On the Zend Developer Zone today there's a new post from Vic Cherubini about a new PHP 5.3 only framework - Jolt.

Since [I wrote a previous framework], PHP5.3 was released and added a whole slew of features. Wanting to take advantage of them, I rewrote (and renamed) the entire framework from Artisan System to Jolt. The interesting thing about Jolt is that it intentionally doesn't come with any type of ORM or ActiveRecord classes. Because I believe that Models should be fat, and controllers skinny, the model framework is left entirely up to the developer.

The README on the github repository talks about why he decided to make his own framework, some of the features and functionality it includes and an example of it in action (a boostrap file).

Jacques Fuentes has submitted some information about an ActiveRecord tool he's developed that's similar to the pattern found in Ruby On Rails and can be found here.

It is extremely similar to ActiveRecord for Ruby on Rails. We believe our project is offering a better programming experience than propel/doctrine since it does not require effort to get started. Propel/doctrine both require that you use yaml/xml files or column mapping in your model classes. We use show fields to 'magically' load this in the background eliminating the tedious requirement of mapping your schema to a file.

The code makes use of some of the features of the upcoming PHP 5.3 release (but won't work with versions prior to that). If you'd like to try it out, you can grab the code here.

DevShed.com has posted the seventh article in their series looking at the Active Record design pattern in PHP applications. In this latest tutorial they show how to replace the older MySQL client libraries and use the newer mysqli client instead.

Well, as you'll surely recall, I built this class by using the old MySQL library included with the PHP distribution, which is good and efficient. But it's worth making the effort to see how this sample class can be rewritten by using the newer, revamped "mysqli" extension. Thus, this last episode will be dedicated exclusively to doing this, so you can have at your disposal an enhanced versions of the class.

For most of the code, you won't see too much of a change - the methods are named similarly and the results are references differently, but you shouldn't have to make too much of a change.

DevShed has the latest article in their tutorial series looking at the Active Record design pattern posted today. This time they focus on a bit of refactoring to make their MySQL abstraction class a bit easier to use and work better.

As I stated in the end of the [previous] tutorial, however, some methods of this sample class implement redundant business logic, and as a consequence it's necessary to refactor them to fix this issue in a quick and simple manner. Thus, in the next few lines I'll be explaining how to accomplish this process progressively, and as always, accompanied by the corresponding code samples.

They change up some of the CRUD (Create, Read, Update, Delete) functions by dynamically constructing the SQL and updating the fetch functions to allow for more modifiers like "LIKE" or "LIMIT".

DevShed continues their series on the Active Record pattern in PHP with this new article implementing the LIMIT statement on your abstraction class.

In its current version, it'll be able to accomplish only a few basic database operations tasks. Therefore, this fifth article of the series will be focused on enabling the class to fetch database rows by using the LIMIT clause.

They add the LIMIT clause as a part of its own function and its own SQL statement. You define the number of rows to fetch, the table to fetch it from and the offset to start from. The SQL is passed off to their fetchRow statement and the results are returned in an array.

DevShed continues their look at the Active Record pattern with the next part of their seven part series - extending their MySQL class even further.

In its current incarnation, this class's functionality is limited, regardless of its decent level of SQL abstraction. Therefore, in this fourth part of the series I'm going to enhance it by making it capable of working with LIKE clauses in a straightforward way.

They look at using LIKE to match values in various columns of the tables and add in a fetchLike method that lets you specify the column to search, the pattern to match on and the table to search in.

DevShed continues their look at the Active Record pattern with this third part of the series focusing on a new method in their class that will make select requests for the Active Record layer.

If you're a PHP programmer who wants to learn how to implement the active record pattern within a MySQL abstraction class to make your database-driven applications more robust and maintainable, then look no further. [...] In this third chapter of the series I'm going to show you how to add a new method to the class. It will be charged with executing conditional SELECT statements via a modified version of the active record pattern.

After reviewing the CRUD functionality from the previous articles, they add in the new method - a fetchWhere function that allows the user to submit a table name and the parameters to add to the where clause as an array. Some sample code is included.

DevShed has posted the next article in their Active Record series. This time it's a look at updating and deleting records from the database (the previous article was about selecting and inserting).

This pattern permits you to achieve a high level of abstraction when performing typical operations, such as insertions, updates and deletions of records, since all of these tasks are handled transparently by data mappers objects or a data access class. [...] Now, it's time to learn how to use the active record pattern for performing database updates and deletions in a few simple steps.

After reviewing the previous article, they add some new features onto the MySQL access class to let you update and remove data through a similar interface.

DevShed has started up a new series looking at one of the more popular software design patterns - the Active Record pattern. In this first part of the series they introduce the pattern and include a little code to get things started.

Using the active record pattern to develop a database-driven application offers many advantages. It can save PHP developers a wealth of time in coding and code maintenance, because you can take advantage of SQL abstraction.

First they set up a simple data mapping class (using methods like setFirstName to change the "firstname" property of the object) then a MySQL abstraction class and, in the last page of this first part, he combines the two to make a simple Active Record example.