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 …