• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Confused about a DAO or a CMR/CMP for Search

 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Dhiren
 
Deepak Pant
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Dhiren,

Yes you are correct. There is no need to involve Entity bean for providing search capability.

I am using following style for providing search:
BD->SessionFacade(SLSB)->ApplicationService(POJO)->DAO(POJO)

Also I will not be caching any intermediate results. The DAO will return the required page size.

Lot of people recommend this approach (Bitter EJB) for performance reasons and I have used it in several of my projects successfully.

Hope this helps

Deepak
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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..

Thanks
Dhiren
 
Deepak Pant
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No it is not duplication of code as what is being searched is beyond the scope of an entity bean. It is based on certain search parameters.

It is not a simple findXXX() method which returns an instance of Entity bean it is a collection of a composite VO (or TO) which will be rendered to the user for selection of a flight.

Once user selects the flight etc and subsequent search of data related to that flight is needed then Flight Entity Bean should be used.

This is the approach I am taking.
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Deepak.
for clarifying my doubt.
Thanks
Dhiren
 
Josep Andreas
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Urs Peter
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

-------
SCJP, SCWCD, SCBCD, IBM485
 
Alastair Calderwood
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Josep,

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.

Alastair
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic