> 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]
