Interesting question... even though the StatementID PK might be specific to your database implementation, it doesn't mean that Statements won't need to be uniquely identified throughout your system. How would one fetch a statement from your system? If that can be done without an ID associated with the object (meaning there is a candidate unique identifier within some other combination of the object's properties), then I guess you could get away without it... but I think 99 times out of 100 you are better off having a property that can uniquely identify an object by itself.
-Dave >>> [EMAIL PROTECTED] 11/14/05 11:11 AM >>> 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] ----------------------------------------- CONFIDENTIALITY NOTICE: This email and any attachments may contain confidential information that is protected by law and is for the sole use of the individuals or entities to which it is addressed. If you are not the intended recipient, please notify the sender by replying to this email and destroying all copies of the communication and attachments. Further use, disclosure, copying, distribution of, or reliance upon the contents of this email and attachments is strictly prohibited. To contact Albany Medical Center, or for a copy of our privacy practices, please visit us on the Internet at www.amc.edu. ---------------------------------------------------------- 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]
