In my recent post regarding the Model Service layer, there was one query about me mentioning that the View is configured by the Controller which goes against the grain of traditional MVC idea of “Views Should handle their own Models / data”.

There is nothing wrong with Views being able to handle their own models, I’m not suggesting that this shouldn’t be the case. You can also do it this way. That is the “traditional MVC” way of doing things and it works fine which is why I’m questioning why I’ve moved away from it. I’m just typing as I go so hopefully by the end of it, we’ll have something that makes a point.

I used to Really love this sh*t!

I used to trumpet the sh*t out of this because I had it figured out and it made me feel smart . I thought hey, I can adhere to the traditional MVC way of things and make the View select it’s own Model (or models) and gather information on it’s own – all I need is a View Helper. Further along came the question “What about the times when the Model needs to be used by the Controller?” well I got a plan for this too, then there’s the “What about when the Controller and View need access to the same model?” case. I needed to create a strategy to make sure that the Model isn’t instantiated twice in these cases.

This is how I did it: Components you need to code up to make it so that the View can choose it’s own Models

Step 1: I created a Model Service Factory which I stored in Zend_Registry – the Model Service Factory has a Registry of it’s own and checks to see if an instance of the Model being requested already exists – if it does, it returns that instead of creating a new instance.
Step 2: I created a View Helper called “GetModel” which accesses the Zend_Registry to access the Model Service Factory and returns the model
Step 3: I then created an Action Helper called “GetModel” which worked exactly like the View Helper.

But then, I found myself questioning if the view selecting it’s own models / data applies to PHP, or if all this complexity is worth anything useful aside from saying “I can do it”. Here are some of the things I’m thinking about:

• One of the cases that I’ve found cumbersome is when I need to access  request parameters in the View whether it be for creating a URL. This should be regarded as a data source as well. Does this mean that we have to code up View Helper to access this also? (This isn’t a smart ass rhetorical question either – I really want to know what do you do?)To handle cases where I need to display parameters in the view, I assign the view parameters in the controller something along the lines of:

$this->view->username = $this->_getParam(‘username’);

• Say you need to display session data in the view, how would you go about doing that? Personally, as with the request parameters, I assign the session data to the view in the controller:

$this->view->somesessiondata = $session->somedata;

• Now say we need to get some data from the model… no problem!  I can use the getModel view helper that makes me feel so smart. To do this though, we need to set up the view so that it has the ID parameter.

$data = $this->getModel(‘SomeModel’)->findById($this->id);
// or if we us a view helper for parameters (I said IF – not entirely sure about this yet)
$data = $this->getModel(‘SomeModel’)->findById($this->getParam(‘id’));

Now compare this with providing the data that the view needs via the Controller.

// in the controller
$this->view->data = $this->_service->findById($this->_getParam(‘id’));
$this->view->username = $this->_getParam(‘username’);
$session = new Zend_Session_NameSpace
$this->view->sessionData = $session->sessionData;

// in the view
<h2>User Details</h2>
<?php foreach ($data as $key=>$val) : ?>
<?=$key?>: <?=$val;?>
<?php endforeach; ?>

<p>You have requested the username: <?=$this->username; ?> which is not available. </p>

Also at one point I was thinking why we are fighting so hard to decouple the view from the controller anyway? They are coupled from the file system and have default conventions like indexAction is coupled with index.phtml view script in an index script directory (which matches controller name).

Having said that though, I don’t see a strong case for or against pushing or pulling models to or from the View. Maybe I’m just missing the point somewhere. In any case, I’d be grateful to know (and learn from) what your take is on this subject matter.

So to sum it up, these are the questions that are floating through my head at the moment.

• What are the _specific_ advantages of having the View pull data from the model directly?
• What are the _specific_ disadvantages of having the Controller push data from the model into view member variables?
• Is the example I specified above (creating view helpers, registry, action helpers) overkill just to achieve something that may or may not be a design problem?

After some more thought and lots of research on the subject, I’ve come to a solid point where I actually have something to try out which seems semantic aside from the naming of the class (Service Class) – but this is derived from what some people are talking about in ZF circles starting from Matthew Weier O’Phinney who was coining it as the “Gateway to the Domain” from early on, then later changing it to “Service Class”.

The Service Class

So this is what I chose to go with:  For each model class, I’ve got a Database Agnostic Service class - in fact, it uses the Entities Produced by Doctrine ORM to talk to the database, but isn’t entirely reliant upon Doctrine to Provide the Model Layer on it’s own. Using Doctrine as your Model Layer alone I suppose is better than extending Zend_Db which is highly discouraged by everyone, but you still have the database dependency.

I thought well, I’ve done a lot of feeling around the subject, maybe I’ll just ask around. So over to twitter I go. I sent Matthew Weier O’Phinney a tweet asking if it is right that Doctrine models are relatively empty whilst Model services are filled with business logic and he answered: “Absolutely. Plain old PHP is perfect for entities.” but I had no idea WTF that meant.

The Service Layer uses the Model which is the Entity. My further attempt to clarify the situation and continue discussion didn’t get a response – maybe because I had to condense words and use accronymns to fit the message in or he had just become too busy. So on my own I go again.

After mulling over it a few, I thought I’d just run with what I’ve got. It seems to be semantic, but it has a lot of responsibilities:

• The Model Service Class is a Resource.
• The Model Service uses the ACL layer to check if a Role Identified has the Privileges to make it’s request prior to usage.
• The Model Service creates Entities by using its Model Factory/Finder methods such as FindById it then returns either an array or an Entity based on what Hydration mode was specified (default is array).
• The Model Service creates Forms and uses it for Validation
• The Model Service provides the CRUD methods so that the Controller does not have to worry about instantiating and configuring models to Create Update or Delete data.
• The Model Service uses Zend_Cache and can use caching on non-changing data such as lookup lists status or types and large collections of data used in drop downs, lists or datagrids.
• Although there is no factory for it, the Model Service can create and use other Model Service classes.
• The Service Layer is not passed to the View either. The View is configured by the Controller and has data shoved into properties/member variables.
• The Service Object can be passed to the View if required, so that the View can use the Sevice object to interrogate models on it’s own. We trust that those writing the View Markup will only be using the service object _strictly for reading only_.

I’ve been working with this setup for a few weeks now. This method is very testable and makes for an extremely thin Controller Layer.

What do you guys think?

Have we over engineered this thing? Should it be called the Service Layer as more and more people are coining it as? What suggestions can you make to make this better?

Zend_Navigation makes the management of a web site’s navigation very easy as it allows you to programmatically create the navigation bar by specifying either the URI or Controller, Action and Module properties of a Zend Navigation Page.

To use Zend Navigation, all I had to do was the following:

• Add configuration entries for navigation in the application.ini file.
• Initialise and attach an instance of the Zend_Navigation container class to the navigation helper via the view in the bootstrap.
• Display the navigation bar with Zend_View_Helper_Navigation::menu() or the BreadCrumbs with Zend_View_Helper_Navigation::breadcrumbs() in your layout.phtml file.

Add configuration entries for navigation in the application.ini file

Now I could have configured the Zend_Navigation container by passing the configuration options in an array, but I thought specifying the navigation in the application.ini was easier because it would keep my init method leaner (more on this later). So the first thing I had to do was add configuration entries for navigation in the application.ini file.

Here’s a code sample:

; —
; Navigation
; —
navigation.home.label = home
navigation.home.controller = index
navigation.home.action = index
navigation.users.label = users
navigation.users.controller = system-user
navigation.users.action = index
navigation.help.label = help
navigation.help.controller = help
navigation.help.action = index

Initialise and attach an instance of the Zend_Navigation container class to the navigation helper via the view in the bootstrap

Initialise the navigation object in the bootstrap class – well there’s no explanations needed here. See the code sample.

Here’s a code sample:

protected function _initNavigation()
{
$this->bootstrap(‘layout’);
$layout = $this->getResource(‘layout’);
$view = $layout->getView();
$navigation = new Zend_Navigation($this->getOption(‘navigation’));
$view->navigation($navigation);
}

Display the navigation bar with Zend_View_Helper_Navigation::menu() or the BreadCrumbs with Zend_View_Helper_Navigation::breadcrumbs() in your layout.phtml file

The Navigation view helper has methods such as menu(), breadcrumbs() and some methods for generating a valid xml sitemap() of the navigation container. You already know this, but I’ve included a code sample of how to do this with the menu() method of the Navigation view helper for completeness.

Here’s a code sample:

<!– left –>

<div id=”left”>

<?php echo $this->navigation()->menu(); ?>

</div>

<!– /left –>