Maybe folks could comment on my thoughts? - Most client traffic (web site etc) is read only. I.E. building pages showing store catalogue, browsing available plane seats etc etc. Why run read only traffic through architecture optimized for transactional robustness? That is unless you want to buy more hardware and deliver slow response for everyone.
- Given, the reality of traffic read VS write, I feel that highest performance, scalability and low latency will be from an architecture based on DAO for read only operations from the client - business deligate tier. I.E. from beans called from JSP's directly. - Allow the client tier business deligate methods to direct read only traffic to DAO's. Other methods that are transactional (CRUD), are directed to session bean methods to mediate entity business logic. Local interfaces would speed these operations greatly! - EJB 2.0 local interfaces and coarse grained beans will always eat CPU, RAM and scalability, latency when compared to DAO for read only operations. - Coarse grained beans can actually be a serious resource hog if you don't implement lazy instantiation of the dependant 1:M components. Else you'll be hitting the DB and building the 1:M objects when the "M" part isn't accessed. - Does EJB 2.0 CMP for coarse grained beans implement lazy instantiation of the dependant compents?? If not, or your container vendor hasn't, watch out??... - The "new" best practice EJB architecture as of EJB 2.0, makes sense if you're architecting a shrink wrapped product that has to work with customer supplied DB's and schema's. I don't believe this is very common, nor will be. So why are the Sun J2EE blueprints showcasing this architecture? I don't know. I'll be sticking with the architecture that's based on DAO and EJB for transactions only. BTW, my thoughts on QL vs SQL... QL and CMP is just one more pain that I see folks sinking bunches of time in. You need to own your data and will end up spending the same time needed to write DAOs and SQL anyway, so why not do it? curt > > >I was reading the J2EE design patterns book and it suggested using a Course >- grained approach at building your entity beans (dependent tables accessed >via Data Access Objects). However, after inspecting the new 2.0 specs, and >considering the inclusion of EJBLocalHome and EJBLocalObject, is it >necessary to still follow this recommendation? I personally would rather not >code DAOs, however, if there is a performance gain by doing so, I would. > >Thanks for you advice. >Aaron. >
