One of the tenets of CSLA is that in general, NULL and 0 are the same thing. If you read through all the books (and various forum posts), you'll see that's how Rocky built the framework - NULL's are converted to a type-appropriate default value. If you do have a need to distringuish between NULL and a value, you can do it - but the framework doesn't do it for you by default.
In terms of DataMapper, I can't offer a specific solution - I haven't looked at the code in a long time, and I don't use it. One possibility that comes to mind is to use a decimal?, but I don't know whether DataMapper is smart enough to handle that. In any event, I think you'll encounter situations like this throughout CSLA.
HTH
- Scott
tmg4340:
One of the tenets of CSLA is that in general, NULL and 0 are the same thing.
Let's be careful around this topic.
The SafeDataReader exists to "de-null" values. It is one tiny class in a large framework. The rest of the framework doesn't care what you do with your null values.
Personally, one of my pet peeves is the misuse of null in databases. In my personal experience, almost every database has many columns that allow null values where there's absolutely no business rationale for such a thing. Nor is the column a foreign key, or an empty date - the only two technical reasons for allowing a null value.
Due to all the crappy databases out there, it was (and is) common practice to write data access code to check for, and remove, null values. SafeDataReader just makes this easier.
But you must be aware that you don't need to use SafeDataReader. It is merely a wrapper around your real datareader object. Nothing stops you from using your real datareader that you got from ADO.NET - and thereby getting at the null values and using them as you see fit.
I would hope that "you see fit" means there are specific cases where business users care about the difference between a value that was never entered, and a value that is empty ("", 0, false, etc). That (and the two technical reasons listed above) are the only reasons your database should allow null values in a column - and therefore are the only reasons your app should have to deal with null values.
In any case, we've veered off your original question.
DataMapper is pretty dumb - it just copies values from property to property.
But this comes back to what I was saying earlier. If you really care about null values from a business perspective, then that concept must (by definition) be expressed from the database all the way through to the UI.
Typically DataMapper is used to map web UI values back into the business object. So if your UI represents the null concept, you should be able to map it - though perhaps not with DataMapper.
I say this, because different UI technologies represent null in the UI in different ways (or not at all - in which case you sometimes need to invent the concept). Microsoft has gotten better about this over the past few years, at least on the Windows side. I do little on the web side, so I don't know if Web Forms expresses null values well or not...
Copyright (c) Marimer LLC