Rolling your own Data Mapper looks like a tough job. Maybe look at Transfer ORM as I'm sure this is based on DataMapper (and I think Reactor is based on ActiveRecord)
Alan ________________________________________ From: [email protected] [EMAIL PROTECTED] On Behalf Of Greg Stevens [EMAIL PROTECTED] Sent: 23 June 2008 16:00 To: CFCDev Subject: [CFCDEV] Re: Naming / Coding / Design Standards Just pulled out Fowler's Patterns of Enterprise AA, I haven't fully read this book yet, just a few patterns at a time. But for the layer I am looking for, the one that has all the <cfquery> tags in it, could I use the Data Mapper pattern? I understand these patterns are just starting points, but I am sure that a pattern has to exist for what I am looking for, at least one that is 98% of what I am looking for. I would like to use some known pattern, just to make maintenance and bringing new programmers aboard easier. Thanks again! On Jun 23, 8:41 am, Greg Stevens <[EMAIL PROTECTED]> wrote: > 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: > > > @Greg, > > > > 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 -~----------~----~----~----~------~----~------~--~---
