EJB3 Business Delegates

Question

Is there any reason for making delegate when using EJB3? Because the only real benefit i see from delegate is that it allows to hide lookup and access details of EJB architecture. Well it also provides some decoupling but it's mostly unused, imho. With EJB3 we have injection so now i can just create a variable with @EJB annotation and use it as is. Do i still need delegates? Is this injection resource consuming? I mean if i use it in JSF's request managed beans may be it's still better to use delegates just to lessen these injection calls?

Thank you!

Answer 1

Let's recap the forces of the original business delegate pattern:

• Presentation-tier clients need access to business services.
• Different clients, such as devices, Web clients, and thick clients, need access to business service.
• Business services APIs may change as business requirements evolve.
• It is desirable to minimize coupling between presentation-tier clients and the business service, thus hiding the underlying implementation details of the service, such as lookup and access.
• Clients may need to implement caching mechanisms for business service information.
• It is desirable to reduce network traffic between client and business services.

All these forces are still relevant today -- they are not necessary present in every project, but could.

The main change is that we don't need the business delegate to minimize coupling (the one in italic). Dependency injection solved the problem of lookup and access.

I like the analysis from Adam Bien: one of the point about coupling that is still not solved naturally are exceptions. Exceptions are now unchecked, but still existing. Whether the client is supposed to be completely shielded from EJB exceptions or not depends again on the forces present in the project.

In the case the business delegate pattern was introduced to solve the problem of lookup and access (which I suspect was the case for a lot of project), we effectively don't need it anymore. If the business delegate was meant for other reasons it can still makes sense.

PS: from my own experience, resource injection was never a performance problem (I always had a more serious performance issue elsewhere than the millisecond taken for the injection :)

Answer 2

Business Delegates were just a hack to hide the whole kludge with JNDI lookups and all the related cleanup and error catching. Resource injection came into J2EE through Gavin Kings Seam which basically follows the as-few-layers-as-possible and all configuration in one place principle. So forget about those old patterns and just use normal OO think.

My 2 cents.