I might agree that for simple enough systems, it could end up being that in fact the service layers end up with PersistenceManager logic directly in their methods. But then I might say a language and framework like Ruby on Rails could suit your application better in that case. For any sufficiently complex Java-based enterprise system, a POJO-style data persistence layer naturally evolves, in order to reduce as far as possible the responsibilities the service layer must carry out.

As mentioned by commentators on his blog, the discipline of test-driven design is usually  a strong driver of having a separated set of components that deal with persistence and other data concerns. Not just from the issue over mocking the PersistenceManager, which is certainly a strong driver, but also from design principles.

Service layers marshall requests from clients, and decompose them to call various component layers. Data access layers typically form part of these component layers. A TDD discipline means these data access layers usually end up with more than just CRUD operations.

Furthermore, as a matter of discipline, in any sufficiently complex service layer I prefer not to work directly with database abstractions (i.e. entities that are modelled on database tables and their relationships) but on first-class objects designed to fit directly with the modelled domain. I want those objects to have rich behaviour – the service layer is actually part of their behaviour. I want to start the design of the system by directly modelling those actions, e.g.

passenger.at(origin);
passenger.orderJourney(dispatch, destination);
Vehicle vehicle = dispatch.sendVehicle(origin);
vehicle.pickUp(passenger);
vehicle.arrives(destination).dropsOff(passenger);
vehicle.notify(dispatch);

I do not want these objects to know about database semantics. That is a responsibility of a separated persistence layer, which we may for convienience sake, called the DAO. Even if internally we end up with;

class Passenger {
  at(Location origin) {
    this.origin=origin;
  }
  call(DispatchCentre dispatch, Location destination) {
    dispatch.passengerOrder(this, destination);
  }
}

DispatchCentre at this level, is a service, but we will model it as part of the domain of passengers, locations, and vehicles. Behind that service, it will have a database layer with the semantics as to how it saves and loads the data concerning passengers, locations, and vehicles. I don’t necessarily want the client objects (e.g. the web action) to have to deal with JPA annotated objects. They just deal with objects as much as possible. And I don’t see there’s anything served with developing possibly complex persistence logic directly in the DispatchCentre. In fact, taking a top-down approach, I know pretty much I won’t do that.

Only after I’ve done this initial part of the modelling, will I be concerned as to which of these components can be directly JPA or Hibernate annotated, which are Spring-injected services, which are Session EJBs, and the like. I think starting your modelling from the point of view of having a persistence framework like JPA or Session EJBs or any other ‘archtectural artifact’ leads to an unnatural design.

A couple of years ago I got into an running battle with a developer at my old workplace as to whether the JPA architecture abstracted away enough of the persistence to justify eliminating the database layer. My answer was, and still is, certainly not!

The simple answer to this question is another question – What if you wanted to replace JPA? The users of the data layer, lets call these objects the SessionLayer, need not, and should not know what sort of persistence layer you’re using. JPA does manage to abstract away some annoyances with choosing a specific transactional persistence technology just as Hibernate or Toplink. But what if you need to replace database access with a call to a web service? Convert the entire application to use Spring transactions? Send a non-transactional JMS message? Or just write the data in a flat file? 

If you have an entirely separate data access layer, which encapsulates your data persistence methods from its users, there’s only one place to change. It’s clients need not ever know you made that change. You have isolated the responsibility. JPA, unencapsulated, encourages users of the data layer to consider the method of persistence. Use JPA underneath your data layer.

A blast from the past. What idiot decided this was a good idea?

public interface SomeEntity {
    String getType();
    String getName();
}
 
public interface SomeEntityHome extends EntityHome {
    SomeEntity findBySomeData(String name, String type);
}
 
public class SomeEntityEjb implements SomeEntity, EntityBean {
    public SomeEntity ejbFindBySomeData(String name, String type) {
        // some cogent implementation here
    }
    public String getType() {
        return this.type;
    }
    public String getName() {
        return this.name;
    }
}

Let’s refactor SomeEntityEjb.java shall we? Change that ejbFind method. Then spend the next half hour figuring out what you did wrong – Jboss doesn’t deploy the EJBs! Grep the code-base for “ejbFindBySomeData” … there’s got to be a magic specification of that method somewhere in the code. Nothing found?!  Hmm it’s been years since I’ve dealt with < 3.0 Entity Beans. Struggle to recall the EJB specification .. what are the magical matching methods in the Home interface? Oh yeah, that’s right!  EntityHome has findXXX, EntityBean has ejbFindXXX. Why, in god’s name, why?

No wonder people got dead-set against EJBs (meaning Entity EJBs) back in 2001 or 2002. Ahhh give me Spring and Hibernate anyday. And remember - parallel magic method naming is a stupid idea - especially in a statically typed language that is supposed to let the compiler do the hard work for you. Jesus kill the people who invented this. Please.

I wish I had the scope just to remove all these Entities …

if (log.isDebugEnabled()) {
    log.debug("hello world");
}

1000 times in your code – everywhere you want a debug statement.

But let’s say you don’t want to rely directly on logging framework. So in your infinite wisdom you write a logging Decorator, which decorates the Log4J Logger class.

I mean, now we can rid of all those 1000 if statements, right, and replace it with just one.

public class MySpecialLogger {
    private Logger log = Logger.logger(MySpecialLogger.class.getName());
 
    public void debug(String message) {
        if (log.isDebugEnabled()) {
            log.debug(message);
        }
    }
 
}

But no – not if you are scared to refactor your code. You might end up with;

if (mylog.isDebugEnabled()) {
    mylog.debug("hello world");
}
// do absolutely nothing else
if (mylog.isDebugEnabled()) {
    mylog.debug("goodbye cruel world");
}

Hundreds, if not thousands, of times in your code. And some other programmer can clean it up.

From Google testing blog:

*Clean Code Talk Series*
*Topic: Don’t Look For Things!*

http://googletesting.blogspot.com/2008/11/clean-code-talks-dependency-injection.html

Recently I’ve been doing maintenance work on a system that has a lot of custom-rolled code to do stuff like, look up EJB Home and Remote references. Even though parts of the system are five years old, even then there were a bunch of accepted patterns for getting this sort of work done. However there’s lots of motion, but very little movement. Even mis-named patterns in places (Delegates that aren’t, and so on).