And interestingly while I was presenting to the NY CFUG the other night and trying to justify to OO n00bs why to bother with DAO's at all (as opposed to just throwing the SQL into the service classes) it finally dawned on me that the main reason is unit testing. Sure it is nice to have the separation of business logic vs sql concerns and theoretically you could swap out DAOs using an abstract factory for different dbms's but that is more useful for frameworks than for most of our day to day apps. The killer benefit of abstracting SQL into a DAO is that you can mock it out for your unit testing,
Best Wishes, Peter On Sep 18, 2008, at 10:14 AM, Adam Haskell wrote: > I have to say I agree with Peter's sentiment mostly here. I've > considered putting together a top anti-patterns presentation > specific to ColdFusion and I say I've never had IBO on that list. > That being said DAO has crossed my mind as an anti-pattern. Not so > much b/c it itself is a bad design pattern in ColdFusion but the > consideration of using it or something else is an anti-pattern. That > decision just really should not be a debate, choose one and move on, > oh or generate it with one of the umpteenmillion tools. If you are > spending time figuring this out your application model is already > too data centric, stop using CFCs immediately and just use > structures (ok ok don't do that but hopefully you get my point). > > > Adam Haskell > > > On Mon, Sep 15, 2008 at 10:49 AM, Peter Bell > <[EMAIL PROTECTED]> wrote: > @Eric, > > There isn't anything more ideal about 3 over 4. I happen to like to > have an object.save() method that calls the DAO to persist the > object, but it's no more or less OO than having an > ObjectService.save(Object) method call. Check out Martin Fowlers > classic entry on the anaemic domain model, He suggests that > persistence strategies are orthogonal to whether the domain model is > anaemic. I'd agree. > > 1 and 2 are sometimes done but are not OO. 3 and 4 are both quite > valid approaches. > > Also, I don't think an IBO is an anti-pattern. That would suggest it > is a common approach that should be avoided as it is a bad design. > It may be a kludge, and it may be CF specific, but I'd argue it is a > pattern - not an anti pattern. > > Best Wishes, > Peter > > On Sep 15, 2008, at 10:39 AM, Eric Knipp wrote: > >> Henry I think you have done a good job summarizing the tradeoffs >> with the bean approach. The Active Record pattern which you >> describe in #3 is the "ideal" in terms of OO behavior, but can be >> hard to use because of performance considerations - this is what >> frequently drives migration to some combination of #2/#4. >> ColdFusion has the added problem of object instantiation >> performance penalties beyond what you would expect from many other >> languages - there's another discussion on this topic raging right >> now as the IBO anti-pattern is discussed. >> >> I don't think there is a perfect solution. You will probably be >> forced to compromise some aspect of object-orientedness to get >> better performance characteristics from your application. >> >> On Wed, Sep 3, 2008 at 8:00 PM, Henry <[EMAIL PROTECTED]> wrote: >> >> 'Bean' was introduced to me when I was learning Model-Glue. >> >> While I did bindly use bean as instructed by MG and other tuturials >> on >> MG, I found that: >> >> 1.) Some thinks bean is nothing more than using CFC as a struct to >> hold fields of forms. >> 2.) Some thinks bean is nothing more than representating a table in >> SQL (data-centeric extreme) >> 3.) Some thinks bean is an object that handles everything internally >> and (talks to database) >> 4.) Some thinks bean is an object that handles everything othan than >> talking to database (with external XXXDao.cfc) >> >> I have used a code generator to generate all the getters and setters. >> With code folding support by CFEclipse, I don't mind them too much. >> Using MG together with ColdSpring, it seems the prefered way is to >> code most logics in the Service layer because they will be kept alive >> throughout the lifetime of the application through use of Singleton. >> However, doesn't that lean towards... procedural programming? >> >> I like the idea of having a "fat bean", and with that I can rely much >> less on getters and setters. However, as the object grow larger with >> number of methods, wouldn't initializing the object be too expensive >> on CF8? >> >> What's your take on fat/lean bean? >> >> >> Thanks, >> Henry Ho >> >> >> On Sep 2, 12:13 pm, "Adam Haskell" <[EMAIL PROTECTED]> wrote: >> > I really don't care for the word beans. They just smack of bad OO >> to me, >> > same with transfer objects. Throw beans away, focus on domains >> and what they >> > should DO. Sure maybe it's symantics but I think beans have this >> context >> > about them of just being glorified structures. If you find >> yourself writing >> > more .getXXX or .setXXX then anything else then something is >> either modeled >> > poorly or you are trying to shoe horn something into an OO design >> that >> > simply does not fit. Is this a bad thing? I suppose it depends on >> what type >> > of app you are writing. In general Services should just know how to >> > co-ordinate different parts of the model Asking the model to do the >> > necessary tasks to accomplish larger tasks. Sometimes that might >> result in >> > data passing in or coming out but generally the service should >> focus on >> > behavior of individual domain objects. >> > >> > Adam >> > >> > On Mon, Sep 1, 2008 at 4:44 AM, Alan Livie >> <[EMAIL PROTECTED]>wrote: >> > >> > >> > >> > >> > >> > > Fat beans - thin(ish) services. >> > >> > > Alan >> > > ________________________________________ >> > > From: [email protected] [EMAIL PROTECTED] On >> Behalf Of Henry >> > > [EMAIL PROTECTED] >> > > Sent: 28 August 2008 04:01 >> > > To: CFCDev >> > > Subject: [CFCDEV] fat bean vs fat service? >> > >> > > I wonder what's prefered... should the bean methods work with >> > > properties of a bean, or should the service methods do >> everything to a >> > > bean, by calling all the getters and setters? >> > >> > > What do you use?- Hide quoted text - >> > >> > - Show quoted text - >> >> >> >> >> >> -- >> Eric Knipp >> Advanced Certified ColdFusion MX Developer >> http://erichk.instantspot.com/blog/ >> >> >> > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
