Looking at some posts posted about DAO and CMP/CMR's I am confused about thier usage now. Can some please clarify ? I was of the opinion that for search functionality I cd use simply a DAO becuase I dont want to create all those many Entity beans in memory which are not really going to be used except for creating Value List. and only when customer selects a final option will I go and create the CMR/CMP's. Does that make any sense ? Or do I need to have already created all the cmr/CMP's in my search call if I need to use them at all ?
Thanks Deepak, Yes that is the approach i was taking but in several SCEA posts I saw that CMR/CMP's was recommended over DAO's. My main concern is I have a design where I do use CMR/CMP's but not for searching so is it all right that CMR/CMP's can come in later to create the flight related DO. Wouldnt it be a kinda of duplication of effort once in DAO which searches and creates a flightVO sort of object and then in the EJB entity beans which actually persists the info..
Just to give some input to this thread. I saw an example where they accessed the DAO from a SFSB; so: SFSB->DAO Does not this also solve the caching? The sfsb acts like a sort of shopping cart regards, J
What I miss in the discussion about SFSB DAO's versus EntityBean findXXX() methods is the third solution which is: CMP HOME BUSINESS METHODS.
For clarity reasons: these methods were introduced in the EJB 2.0 spec. They're called on the home interface of the entity bean and do NOT return references to (or Collections of) Entity Beans, instead they return VOs (or collections of VOs). Business Home methods are very fast since the bean does not leave the POOLED STATE, which means no entity bean instances have to be populated. It can therefore be compared to a DAO, with the big advantage that no DAO-framwork incl. all the SQL has to be provided. As a summary, Sun realized the need of being able to read data fastly and CMP HOME BUSINESS METHODS are the answer.
In my assignment I'll use a home business method to read the flight data.
I saw an example where they accessed the DAO from a SFSB; so: SFSB->DAO Does not this also solve the caching? The sfsb acts like a sort of shopping cart
Is there a problem in that SFSBs can't be pooled whereas SLSBs can? The overhead of creating a SFSB for each search might slow it down if the server has reached its capacity, so it seems less scalable but that might be countered by caching results in the SFSB.
permaculture is a more symbiotic relationship with nature so I can be even lazier. Read tiny ad: