views:

207

answers:

1

When using the facade design pattern to structure an application's business EJB layer, why should we still use session beans for the actual business logic? Is there a specific reason for not just using plain Java classes (if container managed injection isn't required)? How is the performance of a plain Java class versus a session bean, wouldn't bypassing business session beans improve performance?

Just to sum up the two options:

  1. CLIENT -> FACADE -> SESSION BEAN
  2. CLIENT -> FACADE -> REGULAR JAVA CLASS

Why use 1 instead of 2?

+2  A: 

The only time I can think that option 1 would make sense if if you need different transactionality from the facade - for example if you wanted to do an update outside of any transaction the facade might be part of.

Otherwise my preference would always be option 2, it's just less crap to eat processor time, go wrong, etc.

Nick Holt
Okay, just to make sure (I know I worded the question this way), but if you needed to access DAOs/PersistenceManager you'd stay with option 1?
Zecrates
@Ristretto: if you've initialized the DAO correctly then the data source it is using will be part of the same transaction the session bean is executing in, so I'd go with option 2 in this case. Only time option 1 makes sense would be if you had multiple operations you want to perform and each needed to be its own or no transaction. Basically, option 1 is the exception rather than the norm and option 2 is generally the way to go. Does that make sense?
Nick Holt
Yes, I think so. This would mean that I won't be able to inject the PersistenceManager, right?
Zecrates
Spring comes with the capability to look-up resources that are in JNDI (see: `jee:jndi-lookup`), which means as long as you look-up the data source your `PersistenceManager` is using you should be alright.
Nick Holt