Nullable types in 2.0, which are a real let down in the fundamental mapping
way, is the best way to deal with the problem.
It's total crap that you can't assign DbNull.Value to a nullable type nad
have it just work. You still need to if value is DbNull.Value in your
mapping layer (both ways), but alteast once that's done, you have access to
x.HasValue for all primitive types (int/bools/blahs)
Assuming you can't move to 2.0...there's no magic solution. On approach is
to not allow nulls for those fields in your database - which makes the
mapping process a lot easier, but isn't practical in all cases. I've used
things like constants assigned to Int32.MinValue - which is a majob problem
waiting to happen.
Just some thoughts :)
Karl
--
http://www.openmymind.net/ http://www.fuelindustries.com/
"Larry Charlton" <La***********@discussions.microsoft.com> wrote in message
news:B5**********************************@microsof t.com...
I posted this a couple of days ago, but it was buried with another
question.
How do people deal with NULL values in an object model?
Consider the following example often used. I can't see anyway to indicate
an age is undefined. So if I get a null from the database what do I store
here and when placing it on the screen, how do I know to put nothing (as
opposed to 0). Is there a methodology people use? Null indicator
variable,
Nullable type, etc. Do I just write compound if statements to test and
determine what to use everywhere? Seems like a very common problem many
other people must be solving in fashion.
Public Class Customer
Private _age As Integer
Public Property Age() As Integer
Get
Return _age
End Get
Set(ByVal value As Integer)
_age = value
End Set
End Property
End Class
