Valid points Seth - but if you can't do the job without using the ID then I think the statement needs to know about the ID and so does everything else.
Since you mentioned his name I'd love to hear if Hal has a different suggestion. But if using the db ID is wrong then I'm almost always wrong :O) Bill On 11/14/05, Seth Johnson (KW) <[EMAIL PROTECTED]> wrote: > > 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] > > > -- [EMAIL PROTECTED] http://blog.rawlinson.us If you want Gmail - just ask. ---------------------------------------------------------- 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]
