Brandon Savage has posted his latest part of his "Peer Review" series. He takesa step back and looks at abstraction again, this time incorporating some of the suggestions other members of the PHP community gave based on the previous version.

This entry will focus on our use of the database, and specifically on the already_tweeted() method. This method has a number of problems, and while we're focusing on the implementation of the database, it's important to note that we will also need to address some of the logic (which will be the next part of the series).

He looks at assumptions (how they can be bad), the use of an ORM layer to help negate some of the problems surrounding them and adding in some exceptions to properly handle issues that might come up.

Brandon Savage has posted his latest article in his series looking at refactoring a piece of code (starting here) focusing in on the abstraction already in the code and how it can be made better.

This article will focus on the constructor method. There are a couple of problems, namely that the constructor itself does a lot of actual work. Also, we have the cURL setup done in the constructor. This object is a Twitter object, not a cURL object; this means that we should decouple the cURL functionality and abstract it into a separate object of its own.

He recommends splitting out the current method the class uses to create the cURL connection (setting it up in the constructor) and making a separate HTTP class that can be pulled in as an object and used as a sort of API. The full code of the new class is also included.

In response to this older post Ralph Schindler has posted some of his own thoughts on database abstraction layers - they must live!

Interestingly, I can put the vocal proponents of each side of the argument in one of two boxes: a programmer guy box, or a database guy box. For some unknown reason though, they never seem to see eye to eye. [...] Generally speaking of database driven projects, I feel like planning to use a specific vendor up front, knowing its pro's and con's, and tailoring an application to the chosen database's strengths can only help in the long run. Also, I feel that building a database model first before any code, offers many performance and scalability advantages than does code first development.

He notes that, while he agrees on the problems with the "switching databases at any time" problems the other author brings up, he points out that the abstraction layers do have their place. He includes an example of an abstraction layer with the Zend_Db object of the Zend Framework. His sample code shows how it can be used to simplify your interaction with your database.

Jeremy Zawodny has shared his opinion on database abstraction layers in PHP applications - they need to die.

Beware of men preaching of false hope. Take, for example, the way some folks feel like they need a database abstraction layer in their applications. [...] So why do folks do it? Because PHP is also a programming language and they feel the need to "dumb it down" or insulate themselves (or others) from the "complexity" of PHP.

He goes on to say that, despite the claims that people make about portability ("it's never that easy") and ease of use, the only real answer is to strip out this layer and use good programming practices to take the database access code out into a separate library that can be replaced quickly and easily.

On PHPBuilder.com today there's a new article looking at how to get PHP and MySQL working together on your server and make the connection between the two in a simple script.

Until you properly understand what happens in the background--on the server--while your code is being processed, you will not have the tools to eliminate slow server responses. I am not, however, talking about the actual machine process that happens on the server. I am simply talking about what happens when you type echo, or print, or foreach. What are you telling PHP to do?

They start with a basic look at working with PHP then move on to creating a simple database interface class. With this in had, they show how to create a simple abstracted query and handle the results.

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 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 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.

On the Blue Parabola blog, Matthew Turland takes a look at object-oriented programming and what core concepts lie at its heart.

What is object-oriented programming? The acronym OOP has become a bit of a buzzword in the current age of programming, to the point where the waters of its definition have become rather murky. [...] PHP may not be object-oriented, but from a purist perspective, neither is Java. What do I mean by "purist perspective?" Plain and simple: everything is either an object or a message being passed between objects (where message parameters are also objects).

He mentions one of the first languages to support objects (Simula) and the four fundamental concepts that would make a language truly OOP - abstraction, inheritance, encapsulation, polymorphism. Its his opinion, though, that while its good for languages to adhere to these four principles as much as they can, discussions about how well they adhere to them is usually just "spinning your wheels" and don't have much use.