July 8, 2011, 4:50 p.m.
posted by franni
Reasons for EJB Objects
Why do we need this second layer of objects? Didn't we move to EJBs from CORBA and RMI to make things simpler? Why not just put all of the logic in your EJBs? There are several reasons for this. First and foremost, this is simply an application of layering. It is never a good idea to place too much behavior in a single object. If you layer the objects called by your EJBs in this way, you can gain the following benefits:
Also, we have found through review of several projects that reuse only rarely occurs at the session level. Each session will have a specific combination of transactional settings and method signatures for a specific application. Having a second layer of objects can instead result in reuse at the inner-layer level, where we have seen reuse in many projects, both within projects (across different session beans) and across projects in the enterprise.
We have seen that if you employ this design strategy then your designs can often use stateless session beans as your façade objects. Since each stateless session bean is not unique to a single user, this allows you to gain the additional scalability that stateless beans provide.
Now we can start to look at what kind of methods the façade will present to the outside world. We have seen that façade methods will usually fall into the following types:
A last point to make about this template architecture involves why we have chosen to use mappers (or factories) to create our DTOs from our entity beans. A potential competing solution to the use of mappers is what [Monson-Haefel] describes as bulk accessors—methods on an entity bean that create and return value objects to represent the data in the entity bean. This is, in fact the solution employed by the CopyHelper access beans in WebSphere Studio. However, this has the unfortunate downside that it assumes that all requests will need all of the data in the EJB—resulting in returning unnecessary data to the user, and (in remote calls) incurring additional overhead for marshalling and unmarshalling the larger DTOs.