Hi Peter, I had an idea yesterday during yesterday's Online CF Meetup with Mark Mandal. When he mentioned slightly about be careful with <onetomany> because of the large amount of objects that Transfer needs CF to create (when w/o lazy loading). Then in my mind <blink>IBO!!!</ blink>. What do you think, Peter?
Henry On Sep 18, 7:22 am, Peter Bell <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
