While preparing the #variables.nextHoliday# dinner, a child asked her mother, "Why do you cut off both ends of ham before you cook it?" The mother responded with, "This is how my mother did it. I don't know why, you should ask her?" When the child asked her grandmother, she got the same response as before. She proceeded to ask her great- grandmother who responded with, "I cut off both ends of the ham because I didn't have a pan big enough."
As programmers, we often make decisions and writing code based on the way we learn how other people did something, but not understanding why. When it comes to programming, we always like to ask the quetion "What's the best way to do X?" Everyone has opinions are are willing to share them. Knowledge sharing is a beautiful thing. When it comes to best practices, the real answer is that it depends on the context for which you're crafting a solution. -Dutch Rapley On Sep 3, 9: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 - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
