Leaking Abstraction

Being new to MVC’s is a bit confusing. There’s a lot of acronyms to understand before you can really start jumping in and coding anything. This couldn’t be any more true for ZF — ZF not only gives you a framework full of buzzwords, it also leaves the interpretation of what each really means up to you.

As a disclaimer, I have to admit that I am no where near the genius of someone like Matthew Weier O’Phinney. If you are, you probably will get little to nothing out of this blog post. In that case, I recommend you read this slideshow on service layers, presented by the lead ZF developer and guru himself.

I read and re-read those slides many times — but I’m the type of person who doesn’t understand something until I’ve experienced it. I was running into a problem with my MVC apps where I was re-writing controller code for manipulating models quite often. Throw AJAX into the mix and suddenly I’m copying and pasting whole actions almost completely. Throw a public facing web service into the mix and I’ve tripled my code size. My my, not very pragmatic at all.

Implementing the service layer

So, what’s a programmer to do? If you’re following the paradigm that controllers are solely for accepting input and rendering output, which I do, then the problem you have — that is, the code you’re copy and pasting — needs to be re-used instead of re-copied. This is where the service layer comes in for me. The service layer becomes a common API for all your controllers to use – whether through AJAX, Web service, or your plain old webpage controllers.

For example, I have a service I call Service_User. This service contains static methods for reading and writing user models. Example method skeletons look like this:

class Service_User {
public static function save($user_id,$data) {
// Neat things happen here that saves a user model
}
public static function fetchAll($params) {
// Neat things happen here that returns a collection of user models
}
public static function delete($user_id) {
// Neat things happen here that deletes a user from the database
}
}

Now, all I have to worry about in my controllers is transforming the incoming data to correspond to the parameters of my service layer. My admin module, ajax module, and normal member controllers now all touch the very same code.

Why don’t I just make my model methods more useful?

This was my gut reaction as well. Indeed, this is what I ended up doing on a whole application. You’ll run into a couple of problems:

• These type of methods generally deal with input and output, while the goal of the model is usually to represent something logically in your application.
• You’ll usually want methods that deal with collections of models, which doesn’t organize well within a model.

I hope this helps clear up some confusion on service layers (well, at least how I use them). Think of them as the API for your application — if you were going to externalize the internals of your application, what functions would you make? The service layer is the glue in between your models and controllers.