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.
blog comments powered by Disqus |
|
|
|
|
|
|
|