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]
