Fat Models and the Data Access Layer
Tuesday, June 17th, 2008There’s been some discussion recently on why active record:
I like the active record pattern, so I don’t think it sucks, but I do think it’s used a little out of context sometimes.
If you’re building a small lightweight app, then I think using your Data access layer as the M in MVC is a logical thing to do. It’s quick, it’s easy and you can extend either your active record in Rails, or extend your Table DataGateway in the Zend Framework and you wont go far wrong.
As soon as your app gets a little more complex, you might want to start creating custom
models that contain more business logic than simply pulling and pushing to the database. If your application is complex enough, chances are your model will need to interact with more than one database table, if not database, so at this point, like Bill Karwin pointed out, your model should be using the DAL, not being the DAL. Loosening the coupling between model and DAL, should also help with automated testing the business logic, in that mock objects could replace the DAL.
The only problem is, I don’t know the best way to do it.
I’m currently learning the ways of the Zend Framework and would be interested to see how people think the best way to implement this kind of complex model. I’m currently leaning toward something like this. I’ve included a Zend_Form object, to show how the Persons model encapsulates more logic than just pushing to and from the database. I think the biggest benefit of Zend_Form is validating input, which I consider domain logic, so should be part of the model. But I’m not sure the best way to make things easily testable, without pushing into the realms of fancy Dependency Injection and what not, which I’m not all that familiar with.
File: application/models/Persons.php
<?php
class Persons
{
public function findByEmail($email)
{
$table = self::getTable();
$select = $table->select()
->where('email = ?', $email);
return $table->fetchAll($select);
}
public static function getTable()
{
// add some dependency injection?
return new Persons_Table();
}
public static function getForm()
{
// add some dependency injection?
return new Persons_Form();
}
// ...
}
File: application/models/Persons/Table.php
<?php
class Persons_Table extends Zend_Db_Table
{
protected $_name = 'persons';
// ...
}
File: application/models/Persons/Form.php
<?php
class Persons_Form extends Zend_Form
{
// ...
}
At first it may seem that the Persons model just ends up acting as a proxy to the Persons_Form and Persons_Table, but once you start writing methods that use both together, you’ll start seeing fatter models and thin controllers, which is all good.
This really is a request for comments really, as I’m personally not sure about the best way to go about this. Would be interesting if any of the people using the MVC part of the Zend Framework in the real world go about this?
