I would appreciate your suggestions and comments on the following design approach.
In our project we have decided to use Stateless Session EJBs with Containter Managed Transaction.
In our existing design the Bean Class extends a normal java class which contains all the business methods.
public class StatelessEJBBean extends ServiceImpl implements javax.ejb.SessionBean
My architect has been recommending this approach to sepearte business concerns from the actual ejb class. But i have been recommending not to adopt this design as we may loose some of the features provided by
the EJB Container like SessionContext handling etc.
It would be great, if all of you could share your thoughts.
Your suggestions would really help us to make a decision.
Why do you have to inherit from the class which implements the business functionality? If you already have all the business functionality implemented you can just call the business methods from your EJBs.
I could not understand your Architects concern about seperating business class from the session bean. Infact session bean themselves are developed to write some business logic. and designing in the way your architect says will increase one more class.
But yeah one benifit if he is looking forward to may be modularity and again hiding business methods by one more layer. I think He can achieve that with this.
The idea is cool, never let your business logic to know about EJB. It will help you to conduct unit testing.
As your architect suggested it can be achieved by extending or using method calls as Barton suggested.
If you have only one of kind ServiceImpl then you can achieve it by either way.
If I would be asked to take the decision I will go by the way of Barton as it keeps the inheritance option open to handle die hard situations.
Thanks for your comments folks,
Now i have some more bullets to fire.
Thanks once again for your time.