I\'m working with .NET strongly-typed datasets and have a table with a nullable int column (and a nullable DateTime column as well).
Apparently there is a bug with t
DBNull was basically brought in to play to deal with non nullable value types, pre .NET 2.0. Due to the design of ADO.NET, there's no way you can avoid DBNull, unless you chose a more direct approach. DBNull is built-in the core of ADO.NET, so you'll have to learn to live with that, if you want to keep using it.
If you provide your own data transport objects instead of relying on the generic System.Data namespace, you can check (while reading in the results with a data reader) if the value is null, but you'll need some way to generate strongly typed objects and mappings because that's really tedious work.
To the extent of my knowledge, DBNull is built in to the design of ADO.NET and the best way to build your apps if you use that, is to coalesce (normalize) DBNull and null. Basically, provide your own DbConvert class which intercepts DBNull and returns an actual null reference if the value is DBNull. This is a minimal requirement, but as soon as that's done you'll have less DBNull values floating around to worry about.