I think Hal also said in one of his talks that he's putting out at http://www.helmsandpeters.com/, the one on objects for maintainable code, that object orientation isn't perfect, but it's the best model we have so far for building maintainable applications. He also says that the way that objects are mapped to relational databases often involves a bit of compromise. Here's the talk:
http://www.helmsandpeters.com/audiofiles/HAPOL-02-ObjectsForMaintainableCode .mp3 Good to question everything with fresh eyes, but i'm finding there's also a point where you just need to be practical and get the job done. If you wanted to be more of a purist about it, you could have an object generate a UUID for you and use that as the identifier instead of the database. But practically, in most cases i don't think it makes a diff of bitterance. That said, if you really want to follow it up, check out Hal's BaseComponent idea. He's giving every instance a unique identity (it's different than what you're talking about ... because 2 instances created from the same database row would have unique identities). You'll find it in his newsletters. >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Seth Johnson (KW) >Sent: Monday, November 14, 2005 7:34 PM >To: [email protected] >Subject: RE: [CFCDev] Who owns the "ID"? > > >> There may be another way to uniquely identify a >> statement by combining two or more fields. If >> that's the case you probably have a "candidate key" >> in your database that your DAO could use. > >Nope, no combination of fields form a natural key, which is why I went >the route of the identity field. > >My concern wasn't about using the ID field as a key, but more about what >objects were made aware of that key. Everything I've read on proper >software engineering (including this list) promotes decoupling the >object's internal representation from how it is persisted. That made me >question my design, since the statement ID was created _based on_ how it >would be implemented by the database. > >In other words, my system includes an auto-incrementing PK because >that's what the database supported, not because any particular >specification in the problem domain. This made me question whether or >not that approach was a good idea when I refactored to an OO design. > >This whole thing started when I read Hal's "Applied Ontology" newsletter >(http://www.halhelms.com/index.cfm?fuseaction=newsletters.show&issue=123 >104_ontology). Following his advice I tried thinking about Statements >in terms of "if I'm a statement, what do I know about myself?" When I >did that, I discovered that a Statement ID value has no meaning to the >statement itself, only to the persistence layer. > >That's when I got confused, since the ID is necessary for the system to >identify statements, even if individual statements don't need to know >how it happens. > >Thanks for the comments so far, >Seth > > >---------------------------------------------------------- >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] ---------------------------------------------------------- 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]
