When using facade session beans, why should we still use business session beans as well?

0
votes

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?

1
javaejb-3.0business-logicfacade
Do you mean entity bean instead of session bean behind the facade? - Nick Holt
No, I mean session bean. For example, the facade might be a CalculatorFacadeBean whereas the session bean might be an AdditionSessionBean, or something like that. - Zecrates

1 Answers

2
votes

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.