A community in which webmasters can ask for help with topics such as PHP coding , MySQL , IT jobs, web design, IT security.
Current location:homephp forumphp talk in 2008 yearHow to Design Domain Layer Objects to Represent Multiple Objects & Single Object in Zend Framework? - page 1
User InfoPosts
How to Design Domain Layer Objects to Represent Multiple Objects & Single Object in Zend Framework?#1
I'm working on creating a domain layer in Zend Framework that is separate from the data access layer. The Data Access Layer is composed to two main objects, a Table Data Gateway and a Row Data Gateway. As per Bill Karwin's reply to this earlier question I now have the following code for my domain Person object:

class Model_Row_Person
{
protected $_gateway;

public function __construct(Zend_Db_Table_Row $gateway)
{
$this->_gateway = $gateway;
}

public function login($userName, $password)
{

}

public function setPassword($password)
{

}
}


However, this only works with an individual row. I also need to create a domain object that can represent the entire table and (presumably) can be used to iterate through all of the Person's in the table and return the appropriate type of person (admin, buyer, etc) object for use. Basically, I envision something like the following:

class Model_Table_Person implements SeekableIterator, Countable, ArrayAccess
{
protected $_gateway;

public function __construct(Model_DbTable_Person $gateway)
{
$this->_gateway = $gateway;
}

public function current()
{
$current = $this->_gateway->fetchRow($this->_pointer);

return $this->_getUser($current);
}

private function _getUser(Zend_Db_Table_Row $current)
{
switch($current->userType)
{
case 'admin':
return new Model_Row_Administrator($current);
break;
case 'associate':
return new Model_Row_Associate($current);
break;
}
}
}


Is this is good/bad way to handle this particular problem? What improvements or adjustments should I make to the overall design?

Thanks in advance for your comments and criticisms.

posted date: 2008-12-16 16:09:00


Re: How to Design Domain Layer Objects to Represent Multiple Objects & Single Object in Zend Framework?#2
I had made out the solution of this problem. click to view my topic...

hope that hepls.

posted date: 2008-12-16 16:09:01


Re: How to Design Domain Layer Objects to Represent Multiple Objects & Single Object in Zend Framework?#3
I had in mind that you would use the Domain Model class to completely hide the fact that you're using a database table for persistence. So passing a Table object or a Row object should be completely under the covers:<?phprequire_once 'Zend/Loader.php';Zend_Loader::registerAutoload();$db = Zend_Db::factory('mysqli', array('dbname'=>'test', 'username'=>'root', 'password'=>'xxxx'));Zend_Db_Table_Abstract::setDefaultAdapter($db);class Table_Person extends Zend_Db_Table_Abstract{ protected $_name = 'person';}class Model_Person{ /** @var Zend_Db_Table */ protected static $table = null; /** @var Zend_Db_Table_Row */ protected $person; public static function init() { if (self::$table == null) { self::$table = new Table_Person(); } } protected static function factory(Zend_Db_Table_Row $personRow) { $personClass = 'Model_Person_' . ucfirst($personRow->person_type); return new $personClass($personRow); } public static function get($id) { self::init(); $personRow = self::$table->find($id)->current(); return self::factory($personRow); } public static function getCollection() { self::init(); $personRowset = self::$table->fetchAll(); $personArray = array(); foreach ($personRowset as $person) { $personArray[] = self::factory($person); } return $personArray; } // protected constructor can only be called from this class, e.g. factory() protected function __construct(Zend_Db_Table_Row $personRow) { $this->person = $personRow; } public function login($password) { if ($this->person->password_hash == hash('sha256', $this->person->password_salt . $password)) { return true; } else { return false; } } public function setPassword($newPassword) { $this->person->password_hash = hash('sha256', $this->person->password_salt . $newPassword); $this->person->save(); }}class Model_Person_Admin extends Model_Person { }class Model_Person_Associate extends Model_Person { }$person = Model_Person::get(1);print "Got object of type ".get_class($person)."\n";$person->setPassword('potrzebie');$people = Model_Person::getCollection();print "Got ".count($people)." people objects:\n";foreach ($people as $i => $person) { print "\t$i: ".get_class($person)."\n";}"I thought static methods were bad which is why I was trying to create the table level methods as instance methods."I don't buy into any blanket statement that static is always bad, or singletons are always bad, or goto is always bad, or what have you. People who make such unequivocal statements are looking to oversimplify the issues. Use the language tools appropriately and they'll be good to you.That said, there's often a tradeoff when you choose one language construct, it makes it easier to do some things while it's harder to do other things. People often point to static making it difficult to write unit test code, and also PHP has some annoying deficiencies related to static and subclassing. But there are also advantages, as we see in this code. You have to judge for yourself whether the advantages outweigh the disadvantages, on a case by case basis."Would Zend Framework support a Finder class?"I don't think that's necessary."Is there a particular reason that you renamed the find method to be get in the model class?"I named the method get() just to be distinct from find(). The "getter" paradigm is associated with OO interfaces, while "finders" are traditionally associated with database stuff. We're trying to design the Domain Model to pretend there's no database involved."And would you use continue to use the same logic to implement specific getBy and getCollectionBy methods?"I'd resist creating a generic getBy() method, because it's tempting to make it accept a generic SQL expression, and then pass it on to the data access objects verbatim. This couples the usage of our Domain Model to the underlying database representation.

posted date: 2008-12-16 17:33:00


Re: How to Design Domain Layer Objects to Represent Multiple Objects & Single Object in Zend Framework?#4
BTW, I used this as an exercise to learn how to code PHP in the new NetBeans 6.5. It rocks!

posted date: 2008-12-16 17:34:00


Re: How to Design Domain Layer Objects to Represent Multiple Objects & Single Object in Zend Framework?#5
Two Questions: 1) I thought static methods were bad which is why I was trying to create the table level methods as instance methods. Would Zend Framework support a Finder class?

posted date: 2008-12-16 17:59:00


Re: How to Design Domain Layer Objects to Represent Multiple Objects & Single Object in Zend Framework?#6
2) Is there a particular reason that you renamed the find method to be get in the model class? And would you use continue to use the same logic to implement specific getBy and getCollectionBy methods?

posted date: 2008-12-16 18:00:00


Re: How to Design Domain Layer Objects to Represent Multiple Objects & Single Object in Zend Framework?#7
I guess that was really three questions :-)

posted date: 2008-12-16 18:01:00


Re: How to Design Domain Layer Objects to Represent Multiple Objects & Single Object in Zend Framework?#8
Thank you very much for your responses. To clarify the final questions, I am thinking to do actually the opposite, I will want to build a function getCollectionByUserType('admin') for example or getByUserName('albus'). Is it a problem to create a static method for each use case?

posted date: 2008-12-16 18:27:00


select page: « 1 »
Copyright ©2008-2017 www.momige.com, all rights reserved.