I’ve managed to spend some time sitting back and looking over some of hte projects I’ve worked on for the past year or so with the Zend Framework and decided that it was finally time to look into something that has always bugged me since the old Cubix Framework days.
That was the lack of decoupling of my Model layer from the View and Controller layers of my MVC projects. Don’t get me wrong, the applications we’ve written work and work well, but the perfectionist in me simply just refuses to stop trying to mentally refactor old projects.
From the time I had first conceptualised the our in-house MVC framework: Cubix and this is before switching to Zend, something that has left me in Analysis paralysis is the Model layer.
I mean, most things I’ve read usually mention the Model layer as a representation of your applications business logic, but this is left wide open to interpretation. The difficult thing here is, that because the business logic is so specific to projects, there’s no real way of explaining it aside from some really basic examples which turn out to be the equivallent of a Javascript example of: “Hello World.”
Not very useful, examples leave a lot of details out – because there’s no real way of dishing out a good example. Even the Zend Framework’s guestbook example in their Quickstart is a little thin.
Starting my research, I googled the term zend framework model tutorial and one of the entries that piqued my interest was a post by brandon from realm of zod titled: Domain Model Programming With the Zend Framework which talks about using Doctrine ORM instead of Zend DB Table’s Table Data Gateway implementation.
I wasn’t so interested in Doctrine, so I just skimmed past the examples, but he did mention a few links, one link was to Matthew Weier O’Phinney’s blog post on Model Infrastructure – here, Matthew talks about the implementation of the Domain Model Design Pattern and talks about having a Gateway to the Domain using the Gateway pattern from Martin Fowler’s PoEAA (ok – you get the picture, I’ll stop hyper linking).
I thought: Great! So we use the Domain Model Design Pattern (as the model layer) to represent business logic, then create an access point or gateway if you will with a simple API that the model’s client’s can use to make the model do it’s thing!
As oppsed to to how I used to do it which is use the model class as the access point for Business Data and Process.
I browsed through the comments, past all the questions and onto comment #34 where the commen(ta?)tor asks about why shouldn’t we just stick domain login in Zend_Db_Table_Row_Abstract and how muddying the Domain Model by making it aware of the persistence layer (I’m guessing this means database) is equally wrong – why we shouldn’t extend Zend_Db_Table_Row_Abstract is a given, but I thought that he did have a point when he mentioned that persistence and business logic is just as bad.
Enter the Service Layer
Poster #34 added a link to Angry Objects’ one and only blog post: Writing Robust PHP Backends with Zend Framework and just like that, it was clear. This is what I’ve been looking for all this time! Or so it seemed!
Exit the Bloated Service Layer: The Method Described above is actually an Anti-pattern.
Further research then reveals that almost everything mentioned on Angry Object’s post, is what Martin Fowler talks about in 2003 on his Bliki: The Anemic Domain Model anti-pattern.
What should happen now then?
Well the night wasn’t all a loss – the Anemic Domain Model Anti-Pattern page on Martin Fowler’s Bliki actually explains what your Domain Models and what Service Layers are actually for.
So armed with this knowledge, I’ll march forward and develop my next project using the Domain Model with a thin Service Layer – similar, if not identical to, what Matthew was talking about on his blog post on Model Infrastructure) as I go through this and if I find some more free time, I might post some code samples of how I’m going.
And so wraps up yet another night of R&D – Interesting though, thought I had this licked. At least now, I have a few ideas as to which path to take. I’ll be downloading Matthews pastebin app to get some sample source code – should be interesting.
Ben Rowe (8)
Bill Karwin (6)
Kevin (6)
James Horne (5)
Martin (4)
Walter (4)
David Penner (3)
Loïc Frering (3)
Mic (3)
San (3)
Great post. I sifted through all the same resources in an effort to find the same holy grail last year. I’ve found a pretty good balance and I should probably update my article with my latest best practices. I respect your choice to stick with Zend_Db but I’m curious to know how closely you’ve looked at Doctrine. I started with Zend_Db and I found Doctrine to be considerably more mature and feature rich and I’ve used Zend_Db in all of my projects up until my latest ones. I mean migrations are alone enough to sell it. Either way, the great thing about domain model programming is that it doesn’t matter which one you go with and if you end up not liking one, its super easy to switch out the gateway logic. Happy refactoring!
Hey there,
Thank you for your feedback – basically, I’ve not looked at Doctrine just yet because I’m still a little raw with how it all fits in with everything. I’ll be using Zend_Db* while I try and master the concept of Domain Model programming, since it’s what I know. Nothing like grasping the ins and outs of an ORM library while at the same time being on the bring of making a breakthrough in understanding Domain Model Programming.
Thank you for the recommendation regarding Doctrine BTW – I’m sure it’s great, heard nothing but great things about Doctrine, “defacto ORM for php projects” etc. This will actually be a good metric for success, if I can build and replace Zend Db with Doctrine, then I’ll know I’m on the right path.
How about you? any reason why you’ve decided against Zend DB*?
I never actually officially decided ‘against’ Zend_Db. I find it to be a competent ORM solution, I simply found Doctrine to offer some extra features I wanted that Zend_Db did not (migrations for example). Additionally I found the support for complex joins while maintaining the Object abstraction was a bit more mature in Doctrine. I used Zend_Db religiously until I switched to Doctrine so I have nothing but good things to say about it. That being said, I think you nailed it right on the head by determining your success based on how to effortless it is to switch ORMs without needing to modify your models.
You should check out Doctrine 2.0. It’s radically different from earlier versions of Doctrine (which I also stayed away from) and supports true domain modeling.