The Immutable Identity Issue

Coordinator
Nov 22, 2008 at 4:02 AM
While we're building these data access layers, I'm going to do my very best to capture each and every issue we run into and publish how we reasoned about them and resolved them.

Since we've recently began coding (we'll start posting here regularly once we have something a little more substantial - we're starting dead simple) we've run into our first "issue". The ole i3: Immutable Identity Issue. Yes, I just made that up ... and yes, you can use it :) We have a couple of domain entities: Forum and Post. Yes, I know, and I'm sorry ... I know this is a boring scenario, but at least everyone already understands it.

Okay, since in our domain model a Forum and a Post are identifiably unique in our system, they will have ID properties that contain their primary key values in the database - and because of this, they should be readonly on the object, right? Let's assume so for now. Under this assumption we're going to have to take on some complexity while implementing it. We're going to have to set the property when we create the object from the data, but we have to limit it everywhere else. Given this will likely happen in a repository ... and the repository will be in a different namespace/assembly ... how do we scope the property (private/internal/public)? From what I can tell, it looks like the most popular way to deal with this issue is to use private reflection to set the property. But what I want to know, is what do you think about this "issue"?

Is this an issue for you?
How do you scope your identity properties?
And more importantly, why?

Like many others, I have thoughts on this subject ... and I've also heard some creative ways of dealing with it that have varying levels of complexity. I'll share them after I've heard from some of you.

Thanks,
Don 
Nov 30, 2008 at 4:01 PM

Don,

in the past I've not seen this as a permissions issue (i.e. any assembly can set the ID), but rather an immutability issue. So once an entity is created, nothing can change the ID... but I've not usually been concerned about stopping people from creating entities.

Therefore I've tended to have a readonly ID property, with the ID passed into the constructor.

I have once or twice made this constructor "internal", but I suspect this doesn't match your architecture, and to be honest I've never really seen it as important.

Very simple, I know, but this has worked for me!

Hope that helps,

Simon
http://blogs.msdn.com/simonince

Dec 15, 2008 at 2:42 PM
I think immutability of object attributes is a different issue from immutablility of primary keys.  Immutability (and all DRI) in the database is a guarantee about the state of the data when it is committed.  In intermediate states in memory, Objects shouldn't have to enforce every commit-time guarantee about the data.

Also, the lifecycle of a Database Entity is _much_ longer than the lifecycle of an Object, and a single Database Entity will be represented by many different Objects over its lifecycle.  So trying to map immutability in the database to immutability of Object attributes doesn't make sense.  We can invent mappings between the two, but you will be commtting to building storage-state knoledge into the Objects, which isn't necessarily a bad idea, but lots of people don't like to do that.

David
Jan 22, 2010 at 7:52 PM

Hey don,

Its too late to ask but, but how did you deal with the Immutable Identity issue?