I'm working on a Zend Framework (1.7) project with a structure loosely based on the structure of the quickstart application - front controller, action controllers, views & models that use Zend_Db_Table to get to the database. One of my main models relies on some expensive joins to pull up its primary listing, so I'm looking into using Zend_Paginator to reduce the number of rows brought back from the database. My problem is that Zend_Paginator only comes with 4 adaptors, none of which really seem to be a good fit for me.
Passing the paginator into the model feels like it, too, would violate the MVC separation. Is the problem that I've built my model incorrectly, that I'm being to dogmatic about maintaining MVC separation or am I missing a clean, elegant way of sticking all the moving parts together?
You can provide an interface on your models that accepts $current_page
and $per_page
parameters and returns the current page's data set as well as a paginator object.
This way all your pagination code is contained within the model and you are free to use the Db adapters without feeling like you've broken the concept.
Plus, the controller really shouldn't be setting up the pager anyways since you are correct in it being tied to the data (and models are for data, not just database connections).
class Model
{
//...
/**
* @return array Array in the form: array( 'paginator' => obj, 'resultset' => obj )
*/
public function getAll( $where = array(), $current_page = null, $per_page = null );
//...
}