Home arrow PHP arrow Page 2 - Building a Data Access Layer for the Data Mapper Design Pattern

Review: building a simple domain layer in PHP 5 - PHP

In this second part of a five-part series I go one step further in the implementation of the Data Mapper design pattern in PHP 5. Specifically, I build a simple MySQL abstraction class which performs a few common tasks. These include connecting to the database server and running hard-coded queries, fetching database rows and so forth.

TABLE OF CONTENTS:
  1. Building a Data Access Layer for the Data Mapper Design Pattern
  2. Review: building a simple domain layer in PHP 5
  3. Building a basic data access layer
  4. Putting the MySQL abstraction class to work
By: Alejandro Gervasio
Rating: starstarstarstarstar / 3
March 17, 2010

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

Before I begin building the data access layer mentioned in the introduction, I’d like to reintroduce the definitions of the classes developed in the previous article. These classes were the building blocks of a basic domain layer.

Having clarified that, here’s the source code corresponding to the first of these classes, which define the structure for generic domain objects. Take a look at it:

(DomainObjectAbstract.php)

 

 

 

<?php

 

 

 

abstract class DomainObjectAbstract

{

    protected $_data = array();

   

    public function __construct(array $data = NULL)

    {

        if ($data !== NULL)

        {

            // populate domain object with an array of data

            foreach ($data as $property => $value)

            {

                if (!empty($property))

                {

                   $this->$property = $value;

                }

            }

        }

    }

   

    // set domain object property

    public function __set($property, $value)

      {

        if (!array_key_exists($property, $this->_data))

        {

            throw new ModelObjectException('The specified property is not valid for this domain object.'); 

        }

        if (strtolower($property) === 'id' AND $this->_data['id'] !== NULL)

        {

            throw new DomainObjectException('ID for this domain object is immutable.');

        }

        $this->_data[$property] = $value;

    }

   

    // get domain object property

    public function __get($property)

    {

        if (!array_key_exists($property, $this->_data))

        {

            throw new DomainObjectException('The property requested is not valid for this domain object.');

        }

        return $this->_data[$property];

    } 

   

    // check if given domain object property has been set

    public function __isset($property)

    {

        return isset($this->_data[$property]);

    }

   

    // unset domain object property

    public function __unset($property)

    {

        if (isset($this->_data[$property]))

        {

            unset($this->_data[$property]);

        }

    }

}

 

 

 

 

 

 

(DomainObjectException.php)

 

 

 

<?php

 

 

 

class DomainObjectException extends Exception{}

As you can see, the above “DomainObjectAbstract” abstract class encapsulates all of the functionality required for building generic domain objects; it can aggregate and remove properties on the fly, thanks to the implementation of the “__set()” and “__get()” PHP magic methods. Since any concrete domain object inherited from this base class will be a plain data container, testing the object is reduced to performing some basic assertions on it. 

The “User” class below shows how to create a concrete user domain object by way of simple inheritance:

(User.php)

 

 

 

<?php

 

 

 

class User extends DomainObjectAbstract

{

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

}

 

 

 

$user = new User();

$user->fname = 'Susan';

$user->lname = 'Norton';

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

Well, obviously spawning a new user object and assigning a few new properties to it is a simple process that doesn’t bear any further discussion, right? However, there are a few neat advantages to defining domain objects like this. First, they’re easy to test and maintain, and second, they’re completely ignorant of the storage mechanism implemented by the application that uses them.

While this strategy allows you to decouple the domain layer from the data access layer, this benefit comes with a fixed cost: there must exist an intermediate element that bridges the layers. That's the role that a data mapper plays. However, before I start showing a concrete implementation of that mapper, it’s necessary to code, at least for the demonstration purposes, the aforementioned data access layer, so you can see how each element fits into this schema.

With that idea in mind, in the following section I’m going to define a basic data access layer. In this case, it will be comprised of a single MySQL abstraction class. Thus, to see how this whole new class will be developed, click on the link below and read the lines to come.



 
 
>>> More PHP Articles          >>> More By Alejandro Gervasio
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PHP ARTICLES

- Hackers Compromise PHP Sites to Launch Attac...
- Red Hat, Zend Form OpenShift PaaS Alliance
- PHP IDE News
- BCD, Zend Extend PHP Partnership
- PHP FAQ Highlight
- PHP Creator Didn't Set Out to Create a Langu...
- PHP Trends Revealed in Zend Study
- PHP: Best Methods for Running Scheduled Jobs
- PHP Array Functions: array_change_key_case
- PHP array_combine Function
- PHP array_chunk Function
- PHP Closures as View Helpers: Lazy-Loading F...
- Using PHP Closures as View Helpers
- PHP File and Operating System Program Execut...
- PHP: Effects of Wrapping Code in Class Const...

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: