Got it - this is pretty much exactly what I've built. I wasn't building separate components for each method, rather I'm building single components that encapsulate all the DB-specific methods.
The only minor difference is that, right now, the DAO component (my "Broker") doesn't persist with the component but rather is being called transiently using CFINVOKE. Any opinion on that? I go back and forth. I worry that instantiating a broker for every component could be a performance hit, but CFINVOKE is a little clunky and could be more a performance drain. I guess the question is that, in aggregate, is it more expensive to call something transiently or create many instances of it that would only be used rarely? I do like the idea of creating one prototype DAO/Broker that would contain all the needed methods. The DB-specific methods would then extend that (and could use it as a handy template). I'm implementing that now. Thanks for the time. Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Matt Liotta > Sent: Sunday, May 09, 2004 5:50 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Best way to dynamically change method bodies (from > "CFINCLUDE forces var scope into arguments?") > > Whatever you want to call it, you don't need a session save component > for each type of database. For example, assume you have a session > component with a save method that would call the appropriate DB > component to save the session using the DB component's save method. It > might look like the following untested code. > > <cfcomponent output="false"> > <cfset variables.config = ""> > <cfset variables.dao = ""> > > <cffunction name="init" output="false" access="public"> > <cfset variables.config = CreateObject("component", "config")> > <cfset variables.config.init()> > <cfset variables.dao = CreateObject("component", > variables.config.getDAOType())> > <cfset variables.dao.init()> > </cffunction> > > <cffunction name="save" output="false" access="public"> > <cfargument name="session" type="struct" required="true"> > <cfset variables.dao.save(arguments.session)> > </cffunction> > </cfcomponent> > > In the above, the session component gets an instance of a config > component allowing it to determine what DAO to use. Then it creates an > instance of that DAO for later use. When the save method is called it > just uses the DAO instance to save the session. The assumption is that > the config object reads some configuration information to determine > what DAO is appropriate. Thus allowing you to change databases simply > by changing the configuration information. > > Matt Liotta > R337 Consulting LLC > http://r337.com > > > On May 9, 2004, at 5:09 PM, Jim Davis wrote: > > >> First, create your base DB component and however many child components > >> you need for each specific DB. Then, create a session save component > >> that will take care of saving your session to your DB. This is done by > >> the session save component deciding which DB component to use and > >> calling the appropriate methods. I would recommend that the session > >> save component read from a configuration file which DB component to > >> use. > > > > Isn't that (at least sort of) what I have with my "broker" components > > from > > the first message? What am I missing? > > > > In that option I would have a Session_Broker.cfc for each database > > type. > > Creating the session object would also create a reference to the > > application-defined broker component. > > > > Calling Session.save() would just be a fa�ade to call > > "Session.broker.save(this)" (although whether the Broker component is > > persistent or not is still an open question). > > > > The implementation is then abstracted from the user (you want to save > > your > > session you call "session.save()" ) but the DB-specific code is still > > available based on the properties of the application. > > > > The only issue here (which seems to be pretty common in OO) is that > > both the > > Session component and the Session_Broker component need to define the > > same > > method signatures (although one is only pointing to the other). > > > > The way around that would be to persist the broker and make a > > reference to > > it a property of the session object. Then you could call something > > like > > "mySession.Broker.save(mySession)" - which really isn't too bad, I > > guess. > > Then there would be no persistence-related code in the Session > > component at > > all. > > > > I think what you're suggesting that the broker would not be a property > > of > > the session object (the call would be something more like > > "mySessionBroker.save(mySession)"), right? > > > > Something like this (using a broker) is how I'm currently leaning > > since I > > just don't like the downside of the Factory Method for this stuff. > > > > As an aside, I'm using "Session" just as an example: there are several > > components working together: DP_Application, DP_Session, DP_Sessions (a > > collection of the current DP_session components), DP_Request, etc. > > > > Most of them talk to either the database or filesystem for at least > > something (even if only for even logging). All of this works (and > > works > > pretty well, if I may say) but all of it currently uses CFINCLUDEs to > > set > > DB/Filesystem-specific method bodies. > > > > That's what I'm trying to get away from. > > > > Thanks for the help, > > > > Jim Davis > > > > > > > > ---------------------------------------------------------- > > 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]
