|
Not sure I understand why the mapping comment. The
Filter object is exactly like a Bean object in concept except it stores
different items or things users can use to filter the search results. A
single filter property might trigger a search on one or more fields or even
tables for that matter. E.g. You are searching for a name so you enter
'Smith' in a the name form field which in turn gets submitted gets
assigned to the Filter.Name property. This Filter gets passed to a Gateway
search function that then decides to search form name in both the first and last
name columns using 'f_name LIKE '%#Filter.Name#%' or l_name LIKE
'%#Filter.Name#%'. I haven't mapped anything directly to a db in
my Filter.
At some point yes a Filter must get mapped to a
db column or column in order to be used but I do not view this as being
any different than the FirstName property of a Contact object getting 'mapped'
to the f_name field in a db when the Bean is given to a DAO to be
saved. It's the DAO or Gateway's job to do the mapping.
How the DAO or Gateway decide what gets mapped to what is up to those
objects to figure out. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Johnson (KW) Sent: Wednesday, January 11, 2006 11:12 AM To: [email protected] Subject: RE: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects > As for the filter method, wouldn’t this be
a good place to pass in
> a
structure and loop through that structure to create the dynamic
> where clause? ... The difficulty would be in synching the
structure
> items with the fields in the
database.
That's exactly the
line of thinking that lead me to where I am right now. I envisioned
accepting a form post, wrapping the name/value pairs into a struct and then
passing that into the Gateway object as my filter.
However, this smells
a bit funny to me because if I programmatically loop over the struct to build
the query I am coupling the form and the data model together. The
form would have to know how the database field names are spelled (or perhaps the
spelling of the bean's private data members) so that it could build the proper
keys in the struct.
Then I thought about
having the Gateway object provide a mapping service that maps the struct keys to
their corresponding database fields. In other words, my Gateway might have
logic that whenever a key is called "customerType" the value of that key is
applied against the "customer_type" database field.
But I don't really
like THAT approach either, because now I have to find a way of documenting what
keys the Gateway object recognizes so that the clients of the Gateway know how
to build the filter objects.
Another idea I've been playing
with is subclassing GatewayFilter to provide class-specific filtering
options. For instance, I might have a CustomerGatewayFilter that has a
well defined interface for defining search options for Customer data. The
CustomerGateway object would then be responsible for creating the dynamic search
query based on the specialized filter object.
I think that final
option is the cleanest implementation, but it adds yet another class to my
system.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Duba,
Phillip
Sent: Wednesday, January 11, 2006 9:02 AM To: [email protected] Subject: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects Ok, that makes sense
since I thought the getById() method took a single id value not a list of them.
My DAOs have something similar to your read() method and they always return a
singular object whether it’s read or saving data. As for the filter method,
wouldn’t this be a good place to pass in a structure and loop through that
structure to create the dynamic where clause? I figure whatever you may be using
as a controller can construct the structure and pass it into the method this way
you don’t have to worry about StructKeyExists() or IsDefined() or default
checking. That’s the tact I would probably take. The difficulty would be in
synching the structure items with the fields in the database.
Thanks, Phil From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Johnson (KW) Phillip: my getById() method accepts a LIST of
data, not a single value, and therefore can return a multi-row query. For
this reason (and the fact that the resulting data is a query, not an object) I
put it in the Gateway object. My DAO already has a read() method that
accepts a single value and returns a fully constructed
object. Jason: I like the idea of naming the filter object
Filter, not Criteria. I'm kinda embarrased to admit I thought long and
hard for a good name for that object and "filter" never occured to me
:) Nando: I use the same distinctions you do: DAOs
synch up the database and singular objects, while Gateways return queries.
My main question was: in my ad-hoc query method, is it better to have an
argument for EACH field that can be searched, or is it better to construct the
filter as a separate object and then pass a SINGLE argument (that filter) into
the Gateway's ad-hoc query method? Basically, if I have a table with 20 searchable fields I
don't want to have to deal with 20 method parameters. I'd rather construct
the entire filter as an external object and then pass it into the search method,
but I wasn't sure if anyone else was using the same approach (or had something
better to suggest). Thanks everyone for your
comments! 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] |
Title: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects
- RE: Spam:RE: [CFCDev] Ad-hoc queries using Data Gatewa... Jason Daiger
- RE: Spam:Re: [CFCDev] Ad-hoc queries using Data G... Seth Johnson \(KW\)
- Re: Spam:Re: [CFCDev] Ad-hoc queries using Da... Cliff Meyers
