I've had moderate success with a dbo component. A component which for the most part just holds all the DB info (connection info, table/view/storeProc name, common queries). In the base cfc's init() I call a dbo.load() method and pass a filename (dbo.xml). The object gets populated by the file and snapped to the calling cfc.
I say moderate success because I had to roll back one of the main features due to speed issues. Basically the component would start at the calling cfc level and look for dbo.xml. If it isn't there it would move up to the parent level, and so on. What seemed to be slowing the component down were the directory and fileExist calls. So I added the optional argument to load() to specify the dbo.xml. It�s a good little system, especially if your db guy isn't a cf guy. He just updates a simple XML file. As for the fa�ade dilly-o, I have a dir/package for flash and flash alone. My setup looks like com.myCorp.myApplication. Everything under myApplication is public/private. Then I have com.myCorp.Flash.myApplication. Everything under flash is set to remote. The fa�ade cfcs I have there merely take the arguments from flash, clean em' up if needed, and make the call to the core cfc. Which can then clean up the returned data if needed, and send it back to flash. (I find a lot of times I'll even strip out data before sending it to flash.) Also rather than just make facades for everything, I make them as the flash guys need them. They take like 5 secs to write, and that way I know I'm only exposing exactly what's needed and nothing more. I'd also recommend a standardized return object, cfc scope debugging array, and most importantly, a system cfc that you load all cfcs though. These 3 features make a system _very_ developer friendly. It's good to see someone talking about architecture on this list. Everyone time I've asked for opinions I received no reply. Like it's all top secret. Adam Wayne Lehman Web Systems Developer Johns Hopkins Bloomberg School of Public Health Distance Education Division -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Blair Sent: Friday, July 18, 2003 1:02 PM To: [EMAIL PROTECTED] Subject: [CFCDev] CFC Architecture Questions Evening all... Hooray! We've a new project on the horizon ... I've had some vague thoughts on how I'm going to put it all together and thought I'd share my ideas to be shot down in flames by you wonderful people... ;) The system we're developing is basically a backend engine to power a number of different sites, all with similar content -- basically rebranded versions of the same "core" site. There will be one main application built on top of this core, but there will also be a number of rebrands that are done on a bespoke basis, accessing the core data in a number of ways, including flash remoting and web services. So, the archiecture I'm thinking of is as follows: At the bottom is a set of core CFCs to provide the business logic layer. Above that there are two layers which provide a different "interface" into the core methods. The first is what I'm calling the "application engine". This will provide access to the core components to the rebranded sites in much the same way as a controller does in MVC. This will include functionality for caching of objects to save on reinstantiation on each call (basically an object store). The second interface is a "fa�ade" type one which provides both remoting and web service based applications with the correct funtionality. Obviously the presentation layer is provided externally. On top of the application engine will sit a couple of different "views": a user view and an administration view. These in effect will be separate applications. The user view must be lightning fast and I was thinking of using something similar to the pagelet from benorama.com to make sure I'm caching as much as possible, and making use of the object store in the application engine. The admin view will be a complex beast, probably written in fusebox but again using the application engine to access the appropriate core functionality. Finally, there is a requirement for some of the sites running off the engine to be more than just a rebrand and should actually permit bespoke functionality, but all based on the given core. Questions I have: I want to make the core CFCs completely stateless so there is no need to reference any external vars. How should I go about making sure that each instance that requires access to the DB has the DSN available to it -- pass the DSN name through on init()? For the fa�ade interface, I want things to be secured so only the appropriate client can call the remoting methods or web services. How should I go about this? How does anyone recommend setting up the "bespoke" sites, still using the application engine? Simply another "view"? Any suggestions greatly appreciated! Cheers, Tim. ------------------------------------------------------- RAWNET LTD - Internet, New Media and ebusiness Gurus. Visit our new website at http://www.rawnet.com for more information about our company, or call us free anytime on 0800 294 24 24. ------------------------------------------------------- Tim Blair Web Application Engineer, Rawnet Limited Direct Phone : +44 (0) 1344 393 441 Switchboard : +44 (0) 1344 393 040 ------------------------------------------------------- This message may contain information which is legally privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any unauthorised disclosure, copying, distribution or use of this information is strictly prohibited. Such notification notwithstanding, any comments, opinions, information or conclusions expressed in this message are those of the originator, not of rawnet limited, unless otherwise explicitly and independently indicated by an authorised representative of rawnet limited. ------------------------------------------------------- ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
