Thanks for the explanation of the Gateway. It's the best one I've seen
so far, really clicked in. I understand that only simple single record
queries should go in the DAO, and that the DAO should accept / return
beans, but would I be totally crazy to put the 4 CRUD functions from
the DAO, put the query into the Gateway, and then have the DAO CRUD
functions just wrap the DAOs? This would keep all queries inside the
same file, which to me seems nicer than having queries in both the DAO
and the Gateway. To sort of merge my earlier thoughts of having the
DAO just return arrays of objects (actually just 1 IBO in most cases),
could I put all the complex/multi-record/multi-table related functions
into the DAO, but just have them as wrapper's to the actual queries
that the Gateway has in them? I just feel it's nicer if I can have
developers code just to the Bean, Service and DAO. Well really just
the bean and service, but the service layer I would like to keep just
as light weight wrappers to things inside the DAO. If I can just say
use the UserService.findAll() to get all users, and know that service
will return an IBO, then we are set. Ideally though, that Service
would just have a wrapper function to the DAO. The DAO would then get
the query from the Gateway.findAll() and convert the query to an IBO.
Does this make sense? It then seems that if I decide to swap out the
database for MS SQL or XML for some reason, then all I need to change
is the Gateway queries. In the XML example, I would have to parse the
XML and then convert the XML into a query, but the point is nothing in
the DAO or anything touching the DAO would need to change, which to me
seems like some great encapsulation.
I am going to try it later today, but before I do what are your
thoughts? Can I have the DAO as a mid-weight wrapper that performs all
queries using similarly named methods in the Gateway and converts them
to arrays of objects (or an IBO)? These means the 4 common CRUD
functions that typically go in the DAO, would have their actual
<cfquery> tag in the Gateway.
I'm probably over complicating it, but just an example of what I am
thinking:
UserService.save(UserBean) would return UserDAO.save(UserBean)
would return UserGateway.save(UserBean).
You would be able to then add some extra code to the UserDAO.save
method for things such as security checks (even though you can argue
that should be taken care of at the Service level) or type validation
(again, some would argue at the service or bean level) just some
examples of what you *could* do at the DAO level later in the project
when someone requests something.
On Jun 23, 6:47 am, "Brian Rinaldi" <[EMAIL PROTECTED]>
wrote:
> I wrote about the Gateway some time ago
> (http://www.remotesynthesis.com/blog/index.cfm/2007/7/18/What-the-Heck...)
> and based on looking into it, this is a ColdFusion-specific pattern that
> appears to have been introduced by the Mach-II Development Guide that Sean
> Corfield wrote during his days with Macromedia. I believe the pattern was
> probably an answer to a ColdFusion specific problem, which was that object
> instantiation was so expensive as to make arrays of objects generally
> unusable for performance reasons. Thus, the DAO dealt in objects but the
> Gateway dealt in queries - generally speaking anyway.
>
> This, to me anyway, seems to explain why we in ColdFusion separated what
> other languages didn't separate. Creating objects has become less expensive
> in ColdFusion 8 but its still not anywhere near as performant as queries, so
> I am not sure that the pattern has entirely outlived its usefulness - plus
> some of us have just gotten used to separating them based on single object
> queries from multi-object queries. Is it necessary? No. Nonetheless, I am
> also of the opinion that there isn't anything wrong with it either...except
> when users simply create four (or five) CFCs for every object without
> thinking (i.e. Service, Bean, DAO, Gateway).
>
> --
> Brian Rinaldi
> blog -http://www.remotesynthesis.com/blog
> ColdFusion Open Source List-http://www.remotesynthesis.com/cfopensourcelist
> Boston CFUG -http://www.bostoncfug.org
> Adobe Community Expert
> -http://www.adobe.com/communities/experts/members/brian_rinaldi.html
>
> On Mon, Jun 23, 2008 at 8:26 AM, Ronan Lucio <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED],
>
> > Greg Stevens escreveu:
>
> > Regarding 2 - What more common approach where you thinking of? Having
> > a separate DAO and Gateway? Do you personally separate what goes in
> > what purely by if it returns or deals with more than 1 record? Perhaps
> > having the Gateway return objects and talk to the DAO for all the
> > queries is the way to go?
>
> --
> Brian Rinaldi
> blog -http://www.remotesynthesis.com/blog
> ColdFusion Open Source List-http://www.remotesynthesis.com/cfopensourcelist
> Boston CFUG -http://www.bostoncfug.org
> Adobe Community Expert
> -http://www.adobe.com/communities/experts/members/brian_rinaldi.html
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
