In the section that you just read, I promised that you’d learn how to build a data mapper class from scratch. Well, in keeping with that, please look at the following code fragment. It defines the generic structure of an abstract mapper: (DataMapperAbstract.php)
<?php
abstract class DataMapperAbstract { protected $_db = NULL; protected $_table = ''; protected $_identityMap = array();
public function __construct(MySQLAdapter $db) { $this->_db = $db; }
// get domain object by ID (implemented by concrete domain object subclasses) abstract public function find($id);
// insert/update domain object (implemented by concrete domain object subclasses) abstract public function save(DomainObjectAbstract $domainObject);
// delete domain object (implemented by concrete domain object subclasses) abstract public function delete(DomainObjectAbstract $domainObject); } Definitely, the definition of the above “DataMapperAbstract” class brings some interesting things to the table that deserve a deeper analysis. As you can see, this class defines a clean, abstract interface, which via concrete implementations, will perform CRUD operations on domain objects by using an instance of the MySQL adapter. The class not only uses a $_table property to map those operations to a specified database table, but defines another property called $_identityMap. As you’ll see in a moment, this latter will be used for building an identity map to keep track of what objects were fetched from the database. If you're interested in a fuller explanation of the Identity Map and other design patterns, I suggest to you grab a copy of Martin Fowler’s book, Patterns of Enterprise Application Architecture, or visit Fowler's Identity Map page. So far, so good. Having defined an abstract mapper class, the next logical step is to create a concrete one that permits you to work directly with user domain objects. That will be the topic that I’m going to discuss in the next section.
blog comments powered by Disqus |
|
|
|
|
|
|
|