Thanks for the heads up. I’ll definitely check it out for inspiration and if it’s complete enough, maybe I’ll even use it for my service layer.

Thanks again!

Implementing forms and cache actually worked well for me. The reason that it’s not called a mapper, is that I don’t see Service as a mapper.

A Data Mapper deals directly with Data and Domain objects/entities, whereas I see the Service Layer as dealing with functionality. Need a form? Let the service layer do it.

Need to validate a form? let the service layer do it, in ZF’s case, this is done by providing a proxy method to the form’s isValid($data) method.

Rather than placing the logic in the controller layer, all this is encapsulated into a nice utility Service class. We avoid making the Service class from being a god class by making it specific to a controller.

I would say that the Service Layer could even use Data Mappers to fetch data for the controller. Anyone correct me if I’m wrong of course.

One thing I did find difficult was implementing ACL into the Service Layer… Maybe I didn’t look into it as much as I should have… I’ve got a better head on me at this point in time so perhaps I’ll revisit the ACL functionality into the Service layer.

But other than that, I can vouch that I am definitely enjoying what seems to be a very nice separation of concerns between the model and controller layers… So far anyway…

One interesting implementation of a service layer is in the source code to Ben Scholzen’s blog:

http://www.dasprids.de/

It has services, which calls mappers to populate models. Services comes from a dependency injection system. It supports Acl on the services. It even has instructions for a Phing build/deployment.

I have found it to be fascinating and very instructive.

He has released the source code at:

http://site.svn.dasprids.de/trunk

Cheers!

Actually, I believe that is where we stand right now! Looking at developments in the zend framework and a ‘best practice example’ in the quick start tutorial download. http://framework.zend.com/demo/ZendFrameworkQuickstart.zip

I Also believe that this reflects the ideas in the refered post about the Model Infrastructure by Matthew Weier O’Phinney (d.d. December-2008)
http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html

I don’t know about adding the functionality for Acl, Forms, Cache etc to a Mapper/Service class. That particular code would get toooo Hot

The Repository is a type of Service, but has nothing to do with the Service Layer. Repositories are part of the Domain Layer. The Repository provides a higher level of data manipulation, acts as a link between the Domain and Persistence Layers (Entity DAO). The Repository pattern is a very common pattern, and most ORMs use it.

Service classes are not part of the Domain or Persistence Layers and therefore do not provide methods to access data, such as dynamic finders. Dynamic finders are usually found in the Repository.

Some people get confused when they use an ORM for the first time, because they think that ORM is a pattern, and it’s not. Mapping relationships is just a technique that uses different patterns to solve the problem of converting data between incompatible systems, e.g. DataMapper, DAO, Factory, Repository, Service Locator, etc.

app/controllers
app/daos
app/domain
app/persistence
app/repositories
app/services
app/views

I really like GORM, and even though they got rid of the Repositories and DAOs, it allows you to build complex domains using a DDD approach.

I haven’t got that far yet, I’m still using these two patterns:

http://fedecarg.codepad.org/9iWX4l7e

I’ve experienced the example you gave when you were making a point about how there are no good answers and I did as Fowler suggested – err on the side of consistency.

Thank you for contributing. Please keep in touch.