Putting the MySQL abstraction class to work - PHP

If you’re like me, then you want to see how to use the MySQL abstraction class defined in the previous segment. Below I wrote a short example that shows how to utilize the class’s interface to pull out data from a fictional “users” database table and display this information on screen. Here’s the corresponding script:

<?php

require_once 'MySQLAdapter.php';

$db = MySQLAdapter::getInstance(array('host', 'user', 'password', 'database'));

$db->query('SELECT * FROM users');

while ($user = $db->fetch())

{

    echo 'First Name: ' . $user->fname . ' Last Name: ' . $user->lname . ' Email: ' . $user->email . '<br />';

}

As depicted above, putting the “MySQLAdapter” class to work is a fairly straightforward process, meaning that you shouldn’t have any problems enhancing its current functionality. Naturally, the point in building this sample class is to set a basic data access layer that allows you to “justify” the implementation of a data mapper. 

Now, think carefully about the hypothetical scenario that has been created so far: on one hand there’s a domain layer where plain user objects live happily, completely ignorant of the existence of the persistence storage mechanism (read: a single MySQL table). On the other hand, there’s the “MySQLAdapter” class, which is the only building block of the layer that accesses the data stored on that table.

Still with me? Then, ask yourself the following question: how can a user object be saved to its associated table, even considering that its properties might not entirely match the table’s fields? That’s exactly where a data mapper comes in, as this element is responsible for internally solving this incompatibility. The bad news is that data mappers are complex creatures that often require the implementation of other data access design patterns, such as an Identity Map, or in large and heavily-loaded applications, a Unit of Work.

However, for the moment there’s no reason to feel intimidated by these potential issues. In the upcoming article I’m going to discuss how to build a basic data mapper class, so you'll be able to quickly grasp its underlying logic. In the meantime, feel free to read the conclusions below.      

Final thoughts

In this second part of the series I went one step further into the implementation of the Data Mapper design pattern in PHP 5. I built a simple MySQL abstraction class which performed a few common tasks, such as connecting to the database server and running hard-coded queries, fetching database rows and so forth.

The purpose of coding a class like this is to recreate a scenario where an application is split into at least two different layers. The first one is the domain layer, where the domain objects (users, blog posts, etc) live, and the second one is the data access layer, which is built upon the previous MySQL accessing class. For the sake of brevity, the presentation layer will be omitted.

With that scenario already set, the next logical step is building the data mapper classes that will interconnect these two independent layers. However, this topic will be discussed in depth in the next tutorial, so don’t miss it!