DAOs as SLSBs - performance hit?

[chaik]

Should I be worried about performance in an EJB3 application which uses the following pattern?

servlet --> Session Facade (SLSB) ---> DAO (SLSB) ---> Entity Bean

-Typically, I have a DAO per entity bean.

-Implementing the DAO as a SLSB is nice since I can use injection for the entity manager.

-I'm using container managed transactions.

I'm worried about the performance hit of having a session facade SLSB call another SLSB (the DAO).

Thanks!

[mazz]

In my opinion, this should not be a problem - I doubt you would notice any non-trivial performance hit or even care. The I/O going to/from your backend data store (in addition to the data processing performed in the DB) will be the performance bottleneck and probably be orders of magnitude above that which your DAO will introduce.

Worry about hitting the database and the I/O that introduces more than adding a DAO layer. A DAO layer above your entity beans is "a good thing".

'course, all of this is IMHO. :-)

[greening]

I am wondering whether EJB3 persistence renders DAOs obsolete.

[greening]

More on this "EJB3 persistence renders DAOs obsolete":

We typically do not use DAOs in front of highly-complex RAM-based data structures. So what makes databases so special that a DAO pattern emerged?

DAOs became popular in the JDBC days, when you had

queryMethod() {
let's say 100 lines of JDBC code to get a list joined with a set
}

Then came Hibernate, and people argued more weakly for DAOs. The argument I saw said DAOs were good for abstracting different database types (mysql vs. postgresql, etc).

Now with EJB3 we have a situation where the old pattern, DAO, has such weak arguments that eliminating DAOs should be considered "reasonable", and that using a DAO should require justification.

Here's our new line of code:

List resultList =
em.createNamedQuery("userFavoritesEntity.findByUser")
.setParameter("user", user)
.getResultList();

Should this code be in the class that calls the entity? Should this code be in a static method on the entity? Those are questions for a later discussion. The question I pose here is whether this code justifies a new class, a DAO.

In other words, does EJB3 persistence render DAOs obsolete?

[mazz]

Good points. Depends on what you call a "DAO".

List resultList =
em.createNamedQuery("userFavoritesEntity.findByUser")
.setParameter("user", user)
.getResultList();

Where that code lives could be called a DAO, no? And all other places that need to run that query would then call that DAO method to perform that query.

But I see your point.

[persabi]

Going through the EJB3 material around, you really don't see this scenario:

servlet --> Session Facade (SLSB) ---> DAO (SLSB) ---> Entity Bean

where SLSBs access entity POJOs via DAOs in the EJB3 environment. It is the defacto "way" in Spring since the framework is not agnostic to back-end providers (Hibernate, iBatis, JDBC etc)

It seems "as mazz said", some people intermix the DAO and session bean concept; so they have a SLSB but call it a DAO.

I agree with greening and would think that EJB3 does renders DAOs obsolete for us anyway.

[bill.burke]

IMO do what works for you. Design patterns are only guidelines. I prefer writers/authors that say "This is an interesting way to write a piece of code" rather than "This is how you should write your code"

[redijedi]

DAOs are great for some applications. At my company a specific division felt that EJB3's less than stellar stored procedure supprt was enough of a reason to switch to ibatis. The group simply wrote up some slsbs that conformed to the existing interface and hotswapped their old ejb3 daos right out with minimal effort. Yet, if you do not ever forsee swapping out your persistence implementation, then you don't need to bother.

[patrick_ibg]

You could start with a generic DAO pattern that is just a thin wrapper around an entity manager, something like the following:

public interface GenericDao
{
 public <T extends BaseEntity> void save (T entity);

 public <T extends BaseEntity> void delete (T entity);

 public <T extends BaseEntity> void delete (Class<T> clazz, Serializable id) ;

 public <T extends BaseEntity> T find (Class<T> clazz, Serializable id) ;

 public <T extends BaseEntity> List<T> list (Class<T> clazz) ;

 public <T extends BaseEntity> T findByExample (T example);

 public <T extends BaseEntity> List<T> listByExample (T example);
}

Then you'd still have the option to switch your persistence layer should the need arise.