Creating concrete domain objects - PHP

The purpose of coding the previous "DomainObjectAbstract" class was logically to encapsulate as much functionality as possible within a construct that defines generic domain objects. Since this base class is abstract, it's necessary to derive a subclass from it to create concrete domain objects. That's really simple to grasp, right?

Since in upcoming tutorials of the series I'm going to discuss how to build a data mapper that will perform CRUD operations on a MySQL table containing user data, it makes sense to define a "User" class that inherits from the parent "DomainObjectAbstract."

Fortunately, building a class like this is an extremely simple task. Still not convinced? Then take a look at the following code fragment, which will make your doubts vanish: 

(User.php)

<?php

class User extends DomainObjectAbstract

{

      protected $_data = array('id' => NULL, 'fname' => '', 'lname' => '', 'email' => '');

}

Done. Now, there's a "User" class that can be utilized as a container for storing the ID, and the first and last names of any number of users. What's more, if I ever need to create a user domain object and dynamically assign to it some properties, the process would be as easy as this:

$user = new User();

$user->fname = 'Susan';

$user->lname = 'Norton';

$user->email = 'susan@domain.com';

While at a glance, it seems that the earlier "User" class doesn't help too much in implementing the Data Mapper pattern, this first impression is wrong. In reality, this is an impressive breakthrough, as now any domain object spawned from the base "DomainObjectAbstract" class will be a POPO (remember, that's a plain old PHP object) with little or no complexity, which can be easily tested by using any unit testing framework.

And best of all, it won't be coupled to the underlying storage system, as this will be exclusively a responsibility of the data mappers. There are still some additional classes that need to be built first, before we get our hands dirty with the mappers, so for the moment be patient and take a peek at my final thoughts.

Final thoughts

That's all for now. In this first installment of the series, I introduced you to implementing the Data Mapper design pattern in PHP 5. As I explained, the issue this pattern attempts to solve is the strong coupling that often exists between the domain objects present in an application and the underlying persistence mechanism. This benefit comes at a cost, since data mappers add a new layer of complexity. Even so, living with this minor trade-off is really worthwhile, believe me.

So far, I showed how to create a plain user domain object, which is a simple data container. So, what's the next step? Well, obviously at some point it'll be necessary to define a user data mapper class that specifically maps user objects to the corresponding storage mechanism.

In consonance with the example that you saw at the beginning of this article, that mechanism will be comprised of a single MySQL database table, which will store user-related data. Therefore, in the following tutorial I'm going to build a brand new class that will work specifically with that RDBMS.

Don't miss the upcoming part!