> -----Original Message----- > From: Andy McShane [mailto:[EMAIL PROTECTED] > Sent: Friday, October 21, 2005 4:31 AM > To: CF-Talk > Subject: RE: CFC - separate or all in one? > > This thread caught my eye and I would like to add a question of my own if > I > may. I am relatively new to CFC's and am still getting my head around > them. > I have written CFC's that only contain database calls in individual > functions that are all relative to specific areas of my site, so I have a > CFC called matchreport.cfc that handles all select, insert, update & > delete > database calls, this is all that the CFC does, is there anything > fundamentally wrong with doing this or is there a better way to handle > this?
Well... in a way there's never anything fundamentally wrong with what works... but there's often room for improvement. ;^) I'm not one to talk about the "right" way to do OO - I'm still learning myself. But CFC's can be OO or not - so there is no "right" way. It's also hard to say because you've given little detail of what the code does. But... In the OO world something like "MatchReport" would probably represent the Match Report and everything you could do with it. So all of your related DB calls may be in there but so would methods (functions) like "Display()" which would display the HTML version of the report or "Email()" which might send the repot to somebody via email. In other words the CFC would contain everything there was to KNOW or to DO with the Match Report. A group of Match Reports might be represented as an array of CFC instances (instead of a CFQUERY). To do this you might have a helper object, perhaps called "MatchReports" (plural) which had methods like "LoadByName()" or "LoadByIDNumber()". This object could be instantiated and one of those methods run which could return an array of MatchReport instances. Now, for future maintenance, it's often better to split out your DB calls into separate objects. So, for example, your MatchReport CFC might define a "save()" method which stores changes to the report to the database. You can put the SQL for that method directly into the CFC - there's nothing "wrong" with that. However if you needed to change Databases at any time (or simply wanted the option to later distribute the code to users of other DBs) it would be harder to change things. So many people define helper objecs (usually called "Data Access Objects" or "DAOs") which only do the database calls. To change the database you only change the DAOs. (Note that "database" here actually means "persistence entity" as it doesn't really have to be a database. You're DAOs could also link to an LDAP server, XML files, flat files, or anything else which can store and hold data.) Some systems (like, say, mine) also allow the definition of the DAO on the fly. This allows the same codebase to work with any defined data source/database type without changing code. You simple add the code for any new persistence entity as a new set of DAOs and change a config file and you're done. So... I really hope that helps. I feel like I've been babbling. ;^) Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:221821 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
