Hey all, I've been lurking here for awhile as I make my transition from a procedural coder to an OO designer. So far this list has been very helpful, I've even learned things from the flame wars :)
I'm currently refactoring a royalties management system into a OO/CFC based system and I have a question about where in the object hierarchy I should stick primary key ID fields. For example, my system will have a Statement object that represents an accounting statement for a publisher. The data for statements is stored in a database using a "StatementID" PK to uniquely identify each row. But since the StatementID is only a persistence mechanism, and has no "business use" other than uniquely identifying a database row, does it belong in the Statement object? Or should it only be used by DAOs and gateways that are tied to a specific database implementation? (And if it is only of use to DAOs, how do I pass it around my app without tightly coupling myself to that specific database implementation?) For all practical purposes this app will never need to replace the PK identity column with a GUID or other key, and it really doesn't hurt me to throw the ID into the Statement object. But I'd still like to know if there is a better way. Any suggestions or comments would be appreciated! Regards, Seth Petry-Johnson ---------------------------------------------------------- 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]
