The CriteriaObject method sounds interesting - dynamically building the query based on the values of the object. However you would still have to fill this criteria object somewhere before calling getByCriteria()
the other option i can think of which is more like the basic search query where you just pass the values to serch for as optional arguments to the function. eg
getByCriteria( keyword, categoryid ..... sortby, isAscendingOrder)
i can see one advantage here being you could do a really quick and dirty way of marshalling the arguments to the function. eg. getByCriteria(argumentsCollection=form)
but then again a criteriaobject would give you the ability to make the select columns and the table name parameters, hence giving you 1 function that would work for any table.
how do other people imlement search queries ?
Pat
On 1/11/06, Nando <[EMAIL PROTECTED]> wrote:
I wouldn't put getById() in a DAO. I'm not an OO guru by a longshot, but
here's why:
The read method in my DAOs accepts a business object or bean as a required
argument, and populates it from the database. It doesnt' return anything.
The getByID() method in my Gateway returns a query. In general, i would say
that a Gateway method returns a query, and a DAO works as a go-between,
between an object and the database. So for each method in the DAO, the
object is passed in and either the object state is altered to match the
database, or the database is altered to match the state of the object(s).
None of my DAO methods return queries - they all return VOID.
I know others have different concepts concerning Gateway and DAO, some mix
them together. But i've come to separate them on the lines i describe above
because the go-between DAO does one type of thing, and the return-a-query
Gateway does another. The difference is very clear to me and helps me to
organize my app.
Your getByCriteria() method would need to accept arguments, of course. The
critera. From there, your method does what it needs to do to return the
result. Simple. All you're doing is abstracting that query to a method. You
don't need to put on white gloves - go ahead and get your hands dirty.
If you're going to place your gateway in a factory in application scope so
that it's accessible to more than one user, make doubly sure you var scope
all your local variables. That's the only thing you gotta watch.
:) Nando
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]]On
>Behalf Of Duba, Phillip
>Sent: Tuesday, January 10, 2006 6:10 PM
>To: [email protected]
>Subject: RE: [CFCDev] Ad-hoc queries using Data Gateway objects
>
>
>Seth,
>
>I've being doing a bunch of work for a rewrite of our User Group website
>and I've kind of done the following for differentiation between a Data
>Access Object (DAO) and a Gateway:
>
>DAOs: Use to Insert/Update single rows and retrieve a single row based
>on the passing of the primary id of the object into the function. These
>functions also return bean objects or accept these objects as arguments.
>
>Gateways: used to return multiple rows or recordsets or some other form
>of data that is not centralized on a singular bean or by the entity's
>primary id.
>
>I would put getAll() and getByCriteria() into the Gateway and getById()
>in the DAO. I like the idea of the GatewayCriteria method you're
>thinking of using. Hope this helps, but I'm sure others will chime in as
>there is a bunch of different ways to do what you are exploring,
>
>Phil
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On
>Behalf Of Seth Johnson (KW)
>Sent: Tuesday, January 10, 2006 12:03 PM
>To: [email protected]
>Subject: [CFCDev] Ad-hoc queries using Data Gateway objects
>
>I'm trying to set up a data gateway object as part of a new project I'm
>working on, but I don't really know what its methods should look like.
>
>I have a getAll() method that returns all rows from the database and a
>getById() method that accepts one or more ID values and returns the
>corresponding rows. This works fine for simple tables, but I also have a
>large search form where users fill in their criteria for running ad-hoc
>queries. How should I implement this in the DG object?
>
>The approach I'm exploring uses a method called getByCriteria() which
>accepts a GatewayCriteria object. This object contains all of the
>ad-hoc criteria definitions including the data member to match (i.e.
>fieldname), search type (exact match, pattern match, etc) and value(s)
>look for. The data gateway object loops through the criteria and
>creates the dynamic SQL for running that query.
>
>Is there a better way?
>
>Thanks in advance for any suggestions,
>Seth
>
>
>----------------------------------------------------------
>You are subscribed to cfcdev. To unsubscribe, send an email to
>[email protected] with the words 'unsubscribe cfcdev' as the subject of
>the email.
>
>CFCDev is run by CFCZone ( www.cfczone.org) and supported by CFXHosting
>(www.cfxhosting.com).
>
>An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
>
>----------------------------------------------------------
>You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the
>subject of the email.
>
>CFCDev is run by CFCZone (www.cfczone.org) and supported by
>CFXHosting ( www.cfxhosting.com).
>
>An archive of the CFCDev list is available at
>www.mail-archive.com/[email protected]
>
>
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
