Boson, I use a different architecture for displaying pages and editing pages.
For editing pages, yes, i instantiate an BO and a DAO (or several of them, depending on the situation) and use the BO to encapsulate and validate the data moving thru the editing form. Once it validates, i pass the BO instance into a freshly instantiated DAO's persist() method. BUT ... for displaying pages, what i've got is a ServiceObject - a singleton - which contains already instantiated Gateways standing at the ready to query the DB for display data. So no instantiation is involved to display a page. I've done it that way for performance reasons, and it works quite well. While you're reading Joe's articles, which are simply excellent, maybe you might just jump to the cutting edge and try out Arf! http://clearsoftware.net/client/index.cfm?mode=entry&entry=56F8F9B3-E081-2BA C-69717D61203E533E :) > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 03, 2005 4:37 PM > To: [email protected] > Subject: RE: [CFCDev] New to OO, question about inheritance and DAO's > > Thanks for the reply, here's some clarifications to my problem... > > Let's give you a simple answer too ... > I'm really confused as to how to design DAO's for this. I > want to be able to have a pageManager cfc that takes a pageID as a field > and returns either a lecture or activity object. > > To me it depends on whether this is for display or for > editing the page ... i'd do it differently in each case. What does your > PageManager do? Does it display the page? Edit the page? When we say > "Page" do we mean Page Content or just the title, meta description and > name in the link that a visitor clicks on to get to the Page. > > > The pageManager is going to basically handle anything the controller file > requires of pages. it will have methods like: > > getPage() - retrieves a page based on an ID and returns a page object > (with any composite objects, ie lectures have faculties) for the view to > render > getPageForEditing () - retrieves a page object for editing > addPage() - accepts a form submit and validates it, then if its good, > insert information to db > processEditPage() - an UPDATE version of addPage() > deletePage() - deletes a page record > getAllPages() - retrieves a query of all pages > getPageByType() - retrieves a query of pages by a type > etc... > > when I say page I mean page and its content. > > Basically the logic I want the app to follow is > pageManager.getPage(ID) is fired > *pageManager calls a DAO that retrieves a page record (this is where I am > having problems with) > pageManager decides what KIND of page it is by page.getPageType() > pageManger includes appropriate view, which will reflect on any additional > properties of the subclasses (like the lectureView will ask for > lectureNumber, while activityView will ask for activityContent. > > > Do I build multiple DAO's that corresponds to each different > subclass (ie: a lectureDAO and an activityDAO)? > > For editing, i'd build multiple DAO's and i might consider, > but probably wouldn't compose the lecture and activity DAO's into the page > DAO. It depends on what you're actually doing when editing (whether you're > simutaneously editing information about the page AND the activity in one > form for instance.) > > What i'd probably do is just have the pageID be a property > of Activity ... and i'd probably have some ID in there that indicates > where on the page the activity goes (which Container) if there is any > chance at all there there might wind up to be more than one bit of Content > on the Page. > > > Ahh I need to clarify that an Activity is a type of page, as is a lecture. > A page doesn't contain an activity. > Basically I will never actually retrieve a BASE page object. A page is > ALWAYS either an lecture or activity. > > So from what you said, you're suggesting I build a LectureDAO and an > ActivityDAO. I was thinking of that, but then I realize > That in each DAO I will need to basically use the same code to read from a > base Page Table (for shared data like pageID, pageTitle, pageType, etc...) > while I don't mind writing those lines out twice, something tells me there > might be a more elegant way to do this. > > I'm thinking that I might have to make something like a pageDAOfactory > that does something like this: > > <cffunction name="getPage"> > <cfargument name="pageID"> > <cfset var page=""> > <cfset var pageType = 0> > a simple db call to retrieve pageType based on ID, maybe like > pageGateway.getPageTypeByID(arguments.pageID) > <cftransaction> > <cfif pageType eq 1> > <cfset page = createObject("component", > "path.to.lecture").init() /> > <cfset pageDAO.read(arguments.pageID, page)> > <cfset lectureDAO.read(arguments.pageID, page)> > <cfelse> > <cfset page = createObject("component", > "path.to.activity").init() /> > <cfset pageDAO.read(arguments.pageID, page)> > <cfset activityDAO.read(arguments.pageID, page)> > </cfif> > </cftransaction> > > <cfreturn page /> > </cfunction> > > > thanks for the help so far... ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
<<attachment: winmail.dat>>
