When to use POJO and When to use SLSB

Question

we are using EJB3 in our application. Our design aim is to separate persistence layer from Business Layer. So we have developed XXXbean classes to be used as SLSB and XXXRepository classes to be used as persistence classes. We also have POJO that implement reusable NON business logic(get list of countries etc) and we call then service/helper Classes.

We use EJB3 JPA (using Hibernate provider) and Repository classes has all the methods for CRUD operation and the get methods for data access. Currently XXXRepository classes are all POJO and we instantiate these classes directly from the bean XXXClasses or from the service Objects.

Should the XXXRepository classes be SLSB ? what would be the benefits and pitfalls of converting them to SLSB?

Answer 1

An EJB is a container managed bean. This means, that the container manages a lot of options like the transaction, security, resource access (e.g. database) and offers possibilities like timers, remote access or interceptors. Another advantage is the pool and the reuse of instances.

I would say, that if you need something from this container managed options like an entity manager, then use an EJB, in your case an SLSB. But if you don't need any of the provided features, then a usual POJO will do that job.

If the XXXRepository classes are no SLSB, how do they access to the database to perform the CRUD operations? Are you using the Hibernate Session directly? How are the transactions managed? It may make sense to transform thes classes in SLSB and use the injected entity manager for this case.

Adam Bien has written a book called Real World Java EE Pattern. In this book he writes about good EJB architectures and also mentions, which classes should be an EJB (for example a ServiceFacade as a transaction boundary) and which classes can be used as POJOs.