How to model in Java EE?

Question

Let's say, I have decided to go with Java EE stack for my enterprise application.

Now, for domain modelling (or: for designing the M of MVC), which APIs can I safely assume and use, and which I should stay away from... say, via a layer of abstraction?

For example,

1. Should I go ahead and litter my Model with calls to Hibernate/JPA API? Or, should I build an abstraction... a persistence layer of my own to avoid hard-coding against these two specific persistence APIs? Why I ask this: Few years ago, there was this Kodo API which got superseded by Hibernate. If one had designed a persistence layer and coded the rest of the model against this layer (instead of littering the Model with calls to specific vendor API), it would have allowed one to (relatively) easily switch from Kodo to Hibernate to xyz.

2. Is it recommended to make aggressive use of the *QL provided by your persistence vendor in your domain model? I'm not aware of any real-world issues (like performance, scalability, portability, etc) arising out of a heavy use of an HQL-like language. Why I ask this: I would like to avoid, as much as possible, writing custom code when the same could be accomplished via query language that is more portable than SQL.

Sorry, but I'm a complete newbie to this area. Where could I find more info on this topic?

Answer 1

Here is what I believe is the traditional view:

• The entities in your project form the domain model. They should be reusable and not tightly coupled to a persistence technology (I'll come back later about tight vs. loose coupling)
• The business layer, uses the domain model, but also exposes services and other stuffs.
• The data access layer is in charge to persist the domain model (entities) in a persistent store.

An entity should not call the data access layer directly. But the business layer will, in a way to load and persist entities of the domain model.

If you map that to Java EE technologies you usually get something like:

• Entities --> POJO with Hibernate/JPA annotations. Note that annotations do not imply a tight coupling with JPA/Hibernate, the very same POJO could be used somewhere else without Hibernate.
• Business layer --> Session EJB or Spring
• Data access layer --> JPA/Hibernate

That's a rough sketch and there are a lot of possible variants. You can notably skip the session EJB and implement the business layer another way. You can also decide to have the business layer call the JPA/Hibernate Session/EntityManager directly, in which case JPA/Hibernate is really the DAL, or you may want to wrap access the Session/EntityManager into so-called Data Access Objects (DAO).

Regarding HQL, try to stick to what's portable, and if you use native SQL, follow SQL-92 conventions. If stuffs get complicated, maybe introduce DAOs. This way, you know that the only place where there are HQL queries is in the DAOs. You can also first implement the query logic "procedurally" in the DAO, and if you have performance problem, re-implement it with a more complicated HQL query.

EDIT

Regarding your questions in the comment:

The business layer depends on the data layer. If you want the business layer to not depend on Hibernate/JPA then your data layer need to abstract Hibernate/JPA away. If you use DAO for your data layer, that will be the case. The DAO will be the "thin hand-written persistence layer over Hibernate" (to take your words). I would introduce DAO for all entities in your case.

What your are asking is a pretty generic design question. I can not give a definitive recipe for that, nor possibly summarize all variants in one answer as it depends on case by case. For instance, we didn't spoke so far about the problem of transactions, that you usually start in the business layer, but that the data layer must be aware of. This typically depends on the technologies used and your requirements.

Still, here is a list of resources that you might be interested in: the books Pattern of Enterprise Application Architecture, the book Real World Java EE Patterns - Rethinking Best Practices, the book Domain Driven Design and more specifically the patterns Data Access Object, Repository pattern, Open Session in View (if it's for a web app), and maybe Anemic Domain Model.

EDIT 2

Ok, a few more sentences about transactions:

Transactions should conceptually be managed in the business layer; the definition of what needs to be done in one unit of work to be consistent depends indeed on the very logic of the application.

With EJB3, transactions can be declared with annotations and the app. server manages that for you. See this other answer of mine for more information. With Spring you can also mark the transactions declaratively, but I don't know the details. Otherwise you will need to start/stop the transaction yourself. This will be slightly different whether you use JDBC transactions or JTA transactions.

Transactions also relates to lazy loading in Hibernate/JPA. An entity that was lazy loaded, can indeed be loaded only if there is a current transaction. If the transactions is terminated in the business layer, entities that are returned to the presentation layer need to be eagerly loaded.

To circumvent this problem, a popular pattern for web applications is Open Session in View, which I already mentioned. In this case, the presentation layer start/stop the transactions (which is slightly wrong conceptually), but works just fine with lazy loading.

Answer 2

Your domain model and its persistence layer should in theory be separate - there's no need for a class called Entity to know anything about if and how it is persisted, so you could use something like Hibernate to create the persistence layer without polluting the domain model classes themselves. You don't "code the [...] model against this layer" - you code the model, then map it to a persistent store with some sort of ORM layer, where the domain model does not depend on the ORM layer. Obviously the persistence layer will depend on the domain model, but that's fine.

I personally fight shy of using too much HQL with (N)Hibernate for the reason you ask, but there are times where it is unavoidable. You already know, and have yourself highlighted, the main issue there, so you are unlikely to overuse this anyway.