David's Tech Blog

One of my biggest frustrations with most MVC frameworks is that their approach to models are generally broken.  Models should hide the data from the controllers.  A controller shouldn’t need to know anything about the data, including what kind of storage is used.  Most frameworks don’t use this approach.

Suppose, for example, that I have a model for Users.  The model should provide the ability to add a User, remove a User, and update a User.  We’ll also probably need some methods for listing and other ways of manipulating the user information.  However, the model should be written in such a way that if we start with the user information in a database, and later move it to a remote LDAP server, or some SOAP or REST service, or a text file it won’t matter.  All of the controllers should be able to continue to call the same model methods that they were calling before, in the same way, and it shouldn’t matter to them where the data is coming from.  Knowing where the data is stored and how to get it and work with it is the model’s job.

This means that the model should not extend some database class.  The framework’s model structure should not assume that all models use databases.  In general, most discussions of MVC frameworks try to isolate the actual database work from the controllers, but they still require the controller to know too much about the data repository.  The effect is that you could probably move from a MySQL database to SQLite, but if you stop using a database entirely you are going to have some major work to do on your controllers that use that model.  To me, a major measure of success for any MVC approach is how much your controllers have to know about the data.  Less is better.

Zend Framework tries to accomplish this, but they basically do it by not giving you a start at any models at all.  Even if it was a very abstract class it would be nice to have something to extend.  At least that would give people a place to start that’s better than extending one of the DB classes, which just about all of the tutorials and articles on ZF models recommend doing.  ZF’s approach to just leave it entirely out of the framework means most instructions tell people to do it wrong.

I’m not a purist.  I’m a pragmatist.  I don’t care a great deal about patterns for their own sake, in any sort of Platonic sense.  I just want to be able to be lazy when I find out later that indeed change is normal and I need to adapt an application to shifting requirements.  Because as predictable as the weather in Phoenix, just about the time that an inventory application is just about through a couple of iterations and really getting useful, they are going to want to integrate it with some remote POS system, and oh yeah can it get its user information from some place in the cloud rather than the local accounts we wanted to use last week.  I’d much rather say “Sure, that’ll be ready day after tomorrow” than say “DOH!”  That requires the controller to be ignorant about the data repository.