Comments on: .NET Nullable Types and DBNull Expose Design Flaws

By: hfrmobile

hfrmobile — Fri, 19 Dec 2008 09:07:32 +0000

You’re right, the DBNull != null thing is awful. But since .NET 2.0 there are “nullable value types”

e.g.

// C#.NET
int? myInt = null;
DateTime? myDateTime = null;

I assume that there exists something equivalent in VB.NET?

I would’ expect for typed datasets that int? getter/setter is generated for nullable ints and int for not nullable ones …

@David Piepgrass: Yes and no. DBNull.Value is OK when it would be compageable with null but: DBNull.Value != null (strange, I agree ;-))

By: David Piepgrass

David Piepgrass — Wed, 19 Mar 2008 19:18:52 +0000

You are incorrect in saying “As you can see, we can’t have a null value type. So, you can see why the DBNull was added, because .NET needed a way to represent a NULL database value.” No, DBNull was not needed. DataRow["column"] returns an object (a reference type), therefore it could hold null. I have no idea why somebody at Microsoft invented DBNull, because the regular null value would have worked just fine. My hypothesis: it was an idiot.

By: Brad

Brad — Thu, 22 Nov 2007 06:30:33 +0000

An interesting read and I agree with many things you say but I thought I would correct one small thing. Int32 is not a reference type that corresponds to int as a value type. Similarly, your claim of the difference between string and String is flawed. int and string are language-specific aliases for the value type Int32 and the reference type String correspondingly.

int i;

and

Int32 i;

will compile as identical code and become

System.Int32 i;

In VB.Net the aliases are Integer and String for these two types and in both languages, these aliases serve little purpose beyond provide familiarity to people migrating from non-.Net languages.

Strings are not value types at all regardless of the upper or lowercase s.

By: Geoff Lane

Geoff Lane — Fri, 18 Nov 2005 21:52:03 +0000

It’s possible in many cases to “program defensively” in such a way that null values are basically never returned. But there are some applications where null values (especially in a database) are required.

I also completely agree with you about performance. Good design is the place to start, worry about optimizing only when you find problem areas.

I built a data collection and reporting tool where we needed to be able to represent a NULL value in the database to the user as an unanswered question. Of course without NULL value types, you have to either represent it in the database as a “magic number” or create some sort of wrappers around all of your integral values and have a “magic number” in the code. (Hint, doing it in the database makes reporting off the data VERY difficult) Of course Nullable negates the necessity of having this “magic number” hack in place, so it’s valuable in that sense.

I just don’t think it’s necessary to require any of these Nullable/DBNull/Wrapper Object workarounds. If .NET provided a corollary reference type for all of the value types and would allow null references of these reference types, we could handle it ourselves. Minimzing/removing the use or value types because of the difference in semantics for copying, calling methods, etc has the side benefit of decreasing surprise.

By: Brennan Stehling

Brennan Stehling — Fri, 18 Nov 2005 17:26:55 +0000

So far everything I have done with .NET 2.0 has been with a Stored Procedures in SQL Server 2000. And I always wrap my columns which could be null with COALESCE and give it a default value, even if it is an empty String. I did not want to even touch the situation with nulls. My policy with objects is to prevent null values from even being possible. I always construct my variables to some default and the Properties sometimes prevent a null value from replacing the non-null value. It depends on each case. I never want to check if a value returned from a method is a null. Like when I return collections, if there are no values I just return an empty collection, so I can call that function from a foreach loop without checking for a null. For strings I return String.Empty, etc. My code has worked quite well, and it is quite fast. I also never use string, and instead use String. I do not care about optimizations through nuances with value types. I find I get greater performance gains by taking my time to design a caching mechanism which cuts down on the db calls. That is where 95% of your latency will be anyway.