> In my experience with nearly 4 years of Rails development, the biggest > problem with AR comes from how you have to explicitly work around N+1 > query problems.
But that's really an ORM issue. N+1 query problems are one of the places where the ORM abstraction becomes leaky and you have to implement eager fetching as opposed to the default lazy loading. And then you have to look carefully at your object graphs to make sure you don't end up loading your entire database, but that's not made any better by putting the code in a DAO and calling it from a service class - plenty of Java devs have got into performance problems with their hibernate apps by not understanding the cases when you *do* need to think about your database - not just your object model. Again, not trying to come off as an AR apologist, I just don't think n +1 is AR specific - it's ORM specific. Best Wishes. Peter On Feb 9, 2009, at 3:32 PM, Eric O'Connell wrote: > > In my experience with nearly 4 years of Rails development, the biggest > problem with AR comes from how you have to explicitly work around N+1 > query problems. If you want to load a parent-child relationship, say > Course and Student, you need to explicitly state something like: > > Course.find(id, :include => :student) > > Otherwise when you walk the course.students association you'll be > executing a query per-student. Obviously, not a great performance > scenario. > > With regard to the Audit Logging problem, there are numerous ways > around hacking into the AR class itself, such as Observers, or > actually grabbing callbacks. Of course, that's one of the lovely > things about Ruby (or hideous, depending on where you sit) but you can > simply redefine methods deep in the persistence layer (hopefully > you're testing well) which will give you access to any necessary code > points where you can do your audit log. Although there are probably > enough predefined callback hooks that it would be easy to do it > without too much mucking. > > I've never used Groovy/Grails so I can't comment directly on that.. > > On Feb 9, 2009, at 12:20 PM, Peter Bell wrote: > >> >> Err, isn't that the poster child for AOP? If I wanted to log >> persistence, I'd add advice. I also believe hibernate throws before >> and after events on persistence operations, so that'd be another >> option for handling that. >> >> To me, user.save() vs. Userservioce.save(User) seems like a fairly >> small difference, and if you're running into problems with generated >> and hand written code, can't you just extend the generated classes >> and >> put custom code in there (excluding templates which can be a PITA to >> merge generated and custom code - however you slice it. >> >> Not playing AR apologist, but I just wasn't convinced by that >> argument >> per se . . . >> >> >> On Feb 9, 2009, at 2:53 PM, Barney Boisvert wrote: >> >>> >>> No performance implications that I know of. It's the same code, >>> just >>> a question of where it lives. And yes, it is very easy, which is >>> why >>> Rails (and Grails) adopted it. >>> >>> After you get your app built, try adding some audit logging to >>> persistence operations. With persistence mixed into your entities, >>> you'd hosed. So like scaffolding, it's excellent for getting up and >>> running quick, but not necessarily a viable long term solution. >>> >>> cheers, >>> barneyb >>> >>> On Mon, Feb 9, 2009 at 11:47 AM, Dan Vega <[email protected]> wrote: >>>> Are there any performance concerns with the active record approach? >>>> It just >>>> all seems very easy to me which is why I like it. >>>> >>>> 1.) model your domain >>>> 2.) create your controller >>>> 3.) mixin any services needed >>>> 4.) view talks to controller >>>> 5.) data is persisted auto majically :) >>>> >>>> Thank You >>>> Dan Vega >>>> [email protected] >>>> http://www.danvega.org >>>> >>>> >>>> On Mon, Feb 9, 2009 at 2:44 PM, Barney Boisvert >>>> <[email protected]> wrote: >>>>> >>>>> Yeah, in general. Among other benefits, it lets your domain >>>>> entities >>>>> not be coupled to any Grails classes. And if you want to go for >>>>> broke, they don't need to be coupled to Hibernate either. Or even >>>>> JPA >>>>> if you're a glutton for pain. >>>>> >>>>> cheers, >>>>> barneyb >>>>> >>>>> On Mon, Feb 9, 2009 at 11:40 AM, Dan Vega <[email protected]> >>>>> wrote: >>>>>> I got ya. So you would rather do something like >>>>>> >>>>>> user = new User(); >>>>>> user.name = "dan" >>>>>> >>>>>> UserService.save(user) >>>>>> >>>>>> Thank You >>>>>> Dan Vega >>>>>> [email protected] >>>>>> http://www.danvega.org >>>>>> >>>>>> >>>>>> On Mon, Feb 9, 2009 at 2:38 PM, Barney Boisvert <[email protected] >>>>>>> >>>>>> wrote: >>>>>>> >>>>>>> I love Hibernate, I just don't like the ActiveRecord pattern, >>>>>>> where >>>>>>> your entities have the persistence operations on them directly, >>>>>>> instead of separated into DAOs. For example, with ActiveRecord >>>>>>> you >>>>>>> have this: >>>>>>> >>>>>>> u = new User() >>>>>>> u.name = 'barney' >>>>>>> u.save() >>>>>>> >>>>>>> The User type shouldn't know about persistence operations, in my >>>>>>> opinion. Hibernate doesn't care where the persistence code >>>>>>> lives, >>>>>>> just that it's configured correctly. Grails (following Rails' >>>>>>> model) >>>>>>> puts it on the entities (the ActiveRecord pattern). Like I >>>>>>> said, I >>>>>>> works just dandy, but it feels wrong, and can lead you into some >>>>>>> weird >>>>>>> issues with transaction demarcation (among other things), >>>>>>> because it >>>>>>> encourages you to NOT think about separation of concerns. >>>>>>> >>>>>>> cheers, >>>>>>> barneyb >>>>>>> >>>>>>> On Mon, Feb 9, 2009 at 11:16 AM, Dan Vega <[email protected]> >>>>>>> wrote: >>>>>>>> Scaffolding is great for generating a base controller but in >>>>>>>> the end >>>>>>>> as >>>>>>>> you >>>>>>>> said you most likely be rolling your own. I found that >>>>>>>> controllers in >>>>>>>> Grails >>>>>>>> are extremely simple to write and in single line (via spring) >>>>>>>> you can >>>>>>>> inject >>>>>>>> your services which is great. As far as active record goes you >>>>>>>> will >>>>>>>> have >>>>>>>> to >>>>>>>> forgive my lack of knowledge but I don't know much about it. I >>>>>>>> do >>>>>>>> know >>>>>>>> that >>>>>>>> Grails uses hibernate for the persistance layer, can you >>>>>>>> explain what >>>>>>>> you >>>>>>>> don't like about that? >>>>>>>> >>>>>>>> Thank You >>>>>>>> Dan Vega >>>>>>>> [email protected] >>>>>>>> http://www.danvega.org >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Feb 9, 2009 at 2:11 PM, Barney Boisvert <[email protected] >>>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> One gripe I had with Grails is that it's ActiveRecord style >>>>>>>>> persistence. That's as expected, of course, but I'm not a >>>>>>>>> fan. >>>>>>>>> It's >>>>>>>>> simple to wrap up with DAO-style persistence to hide the >>>>>>>>> fact. I'm >>>>>>>>> also not much of a fan of scaffolding, because you invariably >>>>>>>>> end up >>>>>>>>> having to customize, and then you can't regenerate without >>>>>>>>> losing >>>>>>>>> the >>>>>>>>> customizations. You can go crazy with your scaffolding >>>>>>>>> templates to >>>>>>>>> mitigate some of the issue, but it's still hard to get it all >>>>>>>>> right. >>>>>>>>> >>>>>>>>> All that said, for getting something out the door quickly it's >>>>>>>>> awesome. >>>>>>>>> >>>>>>>>> cheers, >>>>>>>>> barneyb >>>>>>>>> >>>>>>>>> On Sun, Feb 8, 2009 at 11:19 PM, Henry <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Has anyone used Rails? loved it? >>>>>>>>>> >>>>>>>>>> I just read a book on introductory of Groovy and Rails. I >>>>>>>>>> wish CF >>>>>>>>>> can >>>>>>>>>> be that easy. I didn't have high hope for CF9's hibernate >>>>>>>>>> integrations before, but now I really wish Adobe got it >>>>>>>>>> right. >>>>>>>>>> >>>>>>>>>> Is it possible to run CFGroovy (with Rails) for M&C, and run >>>>>>>>>> CF >>>>>>>>>> for >>>>>>>>>> V? Just a thought. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Henry Ho >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Barney Boisvert >>>>>>>>> [email protected] >>>>>>>>> http://www.barneyb.com/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Barney Boisvert >>>>>>> [email protected] >>>>>>> http://www.barneyb.com/ >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Barney Boisvert >>>>> [email protected] >>>>> http://www.barneyb.com/ >>>>> >>>>> >>>> >>>> >>>>> >>>> >>> >>> >>> >>> -- >>> 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 -~----------~----~----~----~------~----~------~--~---
