The case study in Cade's book does not use entity bean at all. On page 172, the OrderProcessor StatelessSessionBean calls OrderDAO directly. I thought we could use an entity bean between the two so that OrderProcess->OrderEnityBean->OrderDAO->EIS. Is that because the persistent layer after the OrderDAO is a legacy system? Does it mean that we should avoid using entity bean when dealing with legacy systems? If not, in what situation we should use entity beans when dealing with legacy systens? Thanks for your tips in advance.
X. John Wen<br />SCEA, SCWCD, SCJP, MCAD.NET, MCDBA, MCP
thats correct...since there is legacy system, so cade hasnt used entity bean for 'order'... as u know it, we model on entity bean when the data mapping is not a prob...further from a design view, when the 'object' in question is in shared write mode entity beans r favored.
John, I do think that EntityBeans can be used in the situation of the case study. If you look at the Customer Component Diagram you can see that the CustomerDAO does not use any subsystem to persist the account information. Problem however is that the account information is aggregated from Customer, Address and CreditCard object(s). To solve this you can use the Composite Entity design pattern (see http://java.sun.com/blueprints/patterns/CompositeEntity.html). While I think that with EJB 2.0 this is a good solution (using CMP and CMR), with EJB 1.1 this solution involves quit a lot of coding. I think that Mark Cade with EJB 1.1 in mind chose for the simplest (thus best) solution, but with EJB 2.0 EntityBeans are a viable solution. Edward Peters
I also think that not using EntityBeans is a design choice rather than what is at the backend. Implementing DAO pattern means datasource can be anything. No matter what the datasource, we could still use EntityBeans between the SessionBean and DAO layers. So we assume making DAO calls from SessionBeans is preferred for the Part II solution? Also, isn't BusinessDelegate preferred in between SessionBean and Servlet?