Barney, +1. You'll always need some variant of a DAO. There comes a time in any database driven app where you can issue a query with two joins, or navigate over object arrays with hundreds of thousands of items. The query wins, and you need a DAO to deal with that.
However, there's enormous variation in how DAOs can be provided. In my Hibernate models I attach a thing called a "Finder" to every collection of domain objects. You give it a set of criteria and it returns a list of objects. The default implementation is to translate the criteria into a set of calls on the Jakarta CollectionUtils/BeanUtils library, which essentially iterates over the collection and returns what you want. Up to this point, the domain model is completely independent of the database and can be unit tested with no database in place. However, for a given collection I can specify a finder subclass that turns the abstract criteria into a Hibernate Criteria query instead, or a SQL query, or even do a mix of all three approaches. This finder subclass is a DAO, but no external object knows or cares - there's no object that thinks it has a DAO. So far out of about 80 classes, I've only needed two DAO-style finders - but in those cases, I *really* need them. Jaime > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Barney Boisvert > Sent: Wednesday, 4 March 2009 2:33 AM > To: [email protected] > Subject: [CFCDEV] Re: Presenting on OO - Should I show the > "Gateway" pattern? > > > People will still care about DAOs; separating persistence > code is still useful, it's just very different from CRUD > style code. But you're right, you set up your DSN, point > Hibernate at it, and you only think about objects instead of > the DB. I'd highly recommend everyone that does OO-ish CF to > take a good hard look at Hibernate. Pick up some example > code and play around with it at least. It's an amazing piece > of software, and has so many little things to teach > developers, even if they're not going to be using it in "real > life". In particular, the fact that "you should never build > ORM, it's too damn hard, and there are already existing > solutions." :) > > cheers, > barneyb > > On Mon, Mar 2, 2009 at 11:21 PM, Alan Livie > <[email protected]> wrote: > > I've been playing with Groovy and Hibernate for about a > week now and > > what is brilliant about it is when building something from > scratch you > > no longer think about the db in the way you do usually. > > > > You just create a database and forget about it. You focus on your > > domain model, adding a few Hibernate annotations along the way and > > when you call > > save() in your Hibernate session it creates tables, columns > and saves > > all the data. Inheritance hierarchies etc not a problem. > > > > If cf9 can work with Hibernate in the same way (maybe > annotations in > > cfscript and/or a new attribute on the cffunction tag) then > in a year > > or two no one will even care about DAOs and Gateways. > > > > If you want to understand things like Data mapper, Unit Of > Work etc to > > get an idea of what Hibernate is doing then read Fowler's > Patterns Of > > Enterprise Application Architecture ... then be thankful > someone else > > has done the ORM work because it looks like a complete > nightmare trying to build an ORM! > > > > Alan > > -- > > Barney Boisvert > [email protected] > http://www.barneyb.com/ > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
