Question

How can I eliminate to write $object = new Application_Model_Database() in every controller?

For example for an article controller, I have to type $articles = new Application_Model_Articles() for every controller. Should I put it under viewer controller, action helpers, or any other way?

Answer 1

Your question almost sounds like an OOP best practices question as opposed to a Zend Framework specific question. Regardless of whether or not I’m using a framework, and regardless of what framework I choose, I base when and where I create new objects on testability how many times I have to write $object = new My_Random_Object();.

Speaking specifically to the Zend Framework: Objects I’m going to use everywhere, or almost everywhere, get created in Bootstrap.php. These objects generally include a database adapter, logger, view object, and any plugins I might use. To access these across the application, I’ll create private properties in the appropriate controllers and assign the objects to those properties in the controller’s init() method.

class ExampleController extends Zend_Controller_Action
{

    public function init()
    {
        $bootstrap = $this->getInvokeArg('bootstrap');
        $this->_db = $bootstrap->getResource('db');
        $this->_log = $bootstrap->getResource('log');
        // and so on, and so forth
    }

}

Ideally, models, services, daos, etc, will all be relatively tightly grouped by controller and by action. In my experience, and this is speaking generally, if I have the same model or service class showing up across all of the controllers in my application, I have an organization problem. That being said, any model that shows up in only one action gets created in that action. If it’s across actions in a controller, it gets created in the init() method and assigned to a property. If it shows up across multiple controllers, it gets created in my Bootstrap.php.

(Ideally, everything gets created in the Bootstrap.php, so you can swap out that bootstrap for testing purposes. Sadly, I don’t always do that, and I most often use the principles I outlined above.)