Storing data in Zend_Registry vs class properties - model-view-controller

Question

I'm building a Zend Framework application wherein the Model layer is separated into Services and Models. Controller actions call service methods, which in turn call model methods.
For instance: LanguagesController::addAction() checks if a form is submitted and valid. If so, it passes the form data to Service_Language::add(), where some business logic is applied to the data before calling Model_Language::add(), which effectively adds the record to the database.
This means that most controller actions will need an instance of a service class, and most methods in the service class will need an instance of a model class.
I used to do it like this (example of a Service class)
class Service_Language
{
public function add()
{
$languageModel = new Model_Language;
// perform some business logic and add record
}
public function edit()
{
$languageModel = new Model_Language;
// perform some business logic and edit record
}
public function delete()
{
$languageModel = new Model_Language;
// perform some business logic and delete record
}
}
Not only does it become cumbersome, in more complex applications where your controller actions call multiple Service methods, there's going to be multiple instances of the same Model class, which is just unnecessary.
A colleague told me to look into two options:
keep a Model instance in a property of the Service
keep a Model instance in Zend_Registry
I think the best solution would be the first option. The reason being that Zend_Registry acts as a global container. We don't want our Model instances to be available in our Controller actions, it's bad architecture. What are your opinions on this?
The first option could be implemented as follows:
class Service_Language
{
protected $_model = null;
function setModel()
{
$this->_model = new Model_Language();
}
function getModel()
{
if($this->_model == null)
{
$this->setModel();
}
return $this->_model;
}
public function add()
{
$languageModel = $this->getModel();
// perform some business logic and add
}
}

Answer 1

From your explanation it sounds like your services classes require tightly coupled models.
In which case I don't think public a public getter/setter for your model is necessary - would there ever realistically be a situation where you would need to set another model for the service?
In which case, assigning the model to a property makes sense - why not do this in the constructor?
class Service_Language
{
protected $_model = null;
public function __construct()
{
$this->_model = new Model_Language();
}
public function add()
{
// perform some business logic and add
$this->_model->add($data);
}
public function edit()
{
// perform some business logic and add
$this->_model->edit($data);
}
}

Answer 2

The constructor would have been a good option, but not every method in the service layer needs to have a model instance to do its job, so I ended up doing it like this. I'm relatively new to OOP programming, so I'm wondering if this is a good solution. Any thoughts are more than welcome.
class Service_Language
{
protected $_model = null;
protected function setModel()
{
$this->_model = new Model_Language();
}
protected function getModel()
{
if($this->_model == null)
{
$this->setModel();
}
return $this->_model;
}
// Function where model is needed
public function add($data)
{
// Perform some business logic
$this->getModel()->add($data);
// return something
}
// Function where no model is needed
public function add($data)
{
// Perform some business logic
// return something
}
}