We're all beginners Nando. ;-) Well, except Hal and Sean basically. One thing that's become very obvious to me is that all this OO stuff is highly subjective. Should you composite all those DAO's and BO's? Maybe...maybe not. I think it depends on what you need to do, how much time you have, your performance requirements, and how complex you want to make things.
I can see how it might be easy to fall into Pattern Fever and start going nuts, making factories for everything, abstracting out every possible variation, etc. This seems to lead to a complicated and overdesigned mess. I just try to go with what seems to work best at the time while trying to set myself with the best situation to refactor later. Software is never really done, it's just "good enough for now". Cheers! > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Nando > Sent: Tuesday, January 11, 2005 6:17 PM > To: [email protected] > Subject: RE: [CFCDev] Newbie approach to Composite Entity pattern. > > The problem i ran into awhile back is what happens if your collections are > several layers deep or you have a lot of them? > > A WebHotel has Sites > Sites have Pages > Pages have Templates > Pages have ContentContainers > ContentContainers have multiple ContentBlocks > ContentBlocks have a variety of different ContentElements > ContentBlocks have Versions > Sites have Tasks > Pages have Tasks > ContentContainers have Tasks > Pages have Comments > Content Containers have Comments > etc ... > > Should i be composing all those BO's and DAO's? When? To what purpose? > > I found it was a better use of my time to focus on object relationships > that > make a noticable difference to the performance and user experience of the > app, at least for now. > > It's only in the display of a single page that these elements are > (apparently) composed, but behind the scenes, that's accomplished with > gateways, not populated objects, within a cluster of helper objects > working > together to build a page, none of which are in the list above, related > with > each other in a completely different fashion. Each of the elements > function > pretty much independently when a user is editing a site ... users do that > one element at a time, and the model reflects that. Composition only comes > into serious play where the action is, building page views from a plethora > of dynamic content. > > I'm SURE over time the model i'm currently using and my understanding of > OO > will improve ... but i don't think it will be in this direction. Who knows > tho'? I'm a beginner and i'm sure i'm in for more surprises as things > evolve. > > Nando > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Brian Kotek > Sent: Tuesday, January 11, 2005 9:54 PM > To: [email protected] > Subject: RE: [CFCDev] Newbie approach to Composite Entity pattern. > > > I suppose I don't like the idea of a DAO compositing another DAO. If it > really needs to be this way, one has to ask if the composited DAO is > necessary at all, and if they both shouldn't be combined into a single > DAO that does both. > > I'd agree with Nando's idea to let a higher level object handle this. > > Function deleteArtcile() { > Variables.instance.articleDAO.delete(idArticle); > Variables.instance.commentDAO.deleteAllByArticle(idArticle); > } > > To me, the BlogContentManager should be knowledgeable of the fact that > comments are related to articles. This relationship has to be managed > somewhere and to me it seems to make sense to handle it outside of the > ArticleDAO. I'd let the ArticleDAO worry about articles, let the > CommentDAO worry about comments, and let BlogContentManager worry about > how they are or are not related. It may just be me but it usually seems > like better designs dictate behavior from the top down, rather from side > to side or from the bottom up. > > Of course this is just my opinion, your mileage may vary, etc. ;-) > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > > Of Joe Rinehart > > Sent: Tuesday, January 11, 2005 3:35 PM > > To: [email protected] > > Subject: Re: [CFCDev] Newbie approach to Composite Entity pattern. > > > > Brian, why do you say that? > > > > It'd make sense to me for have the BlogContentManager not know or care > > about the components that make up an article. > > > > If the ArticleDAO is responsible for persisting the state of a given > > Article, it makes sense to me that it would have knowledge of that > > Article's composition, and therefore know the names of the aggregated > > comment component's DAO (or know of a service locator to get it). It > > wouldn't run the delete command explicitly, but use the comment's DAO. > > > > -Joe > > > > > > On Tue, 11 Jan 2005 15:00:34 -0500, Brian Kotek <[EMAIL PROTECTED]> > > wrote: > > > I'd say whatever entity is managing both the articles and the > comments > > > (the "BlogContentManager") would be responsible for removing > comments > > > associated with deleted articles. I wouldn't think it should be the > > > ArticleDAO's responsibility to remove comments. > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On > > > Behalf > > > > Of Patrick McElhaney > > > > Sent: Tuesday, January 11, 2005 2:22 PM > > > > To: [email protected] > > > > Subject: Re: [CFCDev] Newbie approach to Composite Entity pattern. > > > > > > > > Here's a question for those of you who think articles and comments > > > > should be dealt with separately. What happens to the comments when > an > > > > article is deleted? > > > > > > > > -- > > > > Patrick McElhaney > > > > 704.560.9117 > > > > http://pmcelhaney.blogspot.com > > > > ---------------------------------------------------------- > > > > You are subscribed to cfcdev. To unsubscribe, send an email > > > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > > > in the message of the email. > > > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > > > by Mindtool, Corporation (www.mindtool.com). > > > > > > > > An archive of the CFCDev list is available at www.mail- > > > > archive.com/[email protected] > > > > > > ---------------------------------------------------------- > > > You are subscribed to cfcdev. To unsubscribe, send an email > > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > > in the message of the email. > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > > by Mindtool, Corporation (www.mindtool.com). > > > > > > An archive of the CFCDev list is available at www.mail- > > archive.com/[email protected] > > > > > > > > > -- > > For Tabs, Trees, and more, use the jComponents: > > http://clearsoftware.net/client/jComponents.cfm > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at www.mail- > > archive.com/[email protected] > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail- > archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
