At my last position, I was introduced to the formal concept of the Model-View-Controller architecture, specifically by way of Zend Framework. It’s a good framework. I enjoy using it a great deal, if for no other reason than the fact that it isn’t a bondage-and-discipline framework; I don’t have to use ZF’s functionality if I don’t want to.
But, it bears saying that the one function that ZF needs, that it doesn’t have, is a Model class. It has a Controller. It has a View. It has Layouts and Helpers, even a Paginator, for crying out loud, but it has no model. I feel this is a key component to the Model-View-Controller architecture. It’s even mentioned in the name. But ZF has no Model.
This leads, if you’re not careful, or ZF is your introduction to MVC, to a fairly significant error in design. The purpose of the Controller is to direct traffic between the user, the model and the view. Make sure the user should be able to do what they’re trying to do, see if there was a transmission failure in the case of user uploads, but really, your controller needs to small. Skinny controller, fat model, is what an old co-worker of mine advised the team. And I happen to agree with him.
The model is where all the heavy lifting involving your data goes. Controller tells the model, “I want a set of your objects that satisfy these conditions,” and the model goes and gets it. Controller tells the model, “Make an instance of yourself from this data, then store it,” and the model does it. Controller Actions should be tiny. You should be able to see an average of three on a screen.
But if you use ZF and you’re not fantastically careful about it, you’ll end up with a Controller that does all your work. That’s the one advantage I’ve seen about other frameworks like CakePHP. While you pretty much have to use Cake’s functionality, you use MVC correctly.
And that’s why I'm making a ZF application template that, by God, has a basic Model class to be extended.
No comments:
Post a Comment