Database Class Woes

[benvegiard]

I am building classes that closely match up to database tables. These classes have many properties that need to maintain a one-to-one relationship with database fields. The properties are typically string, integer, and DateTime.

Since the database value for a given field may be NULL, I need to somehow store that possibility in the class. I would like to have a property that could retain an actual DB value or reflect that the value is NULL. I do not want to have a second property to store whether or not the field is null.

The solutions I have come up with are:
1) Set the property to some predefined constant indicating that it is a null. For example, declare a constant NULLINTEGER = -99999
2) Declare the property as type object and in the set property code do type validation. Use a private variable to store if the value is null. On the Get Property check the private variable and return DBNULL.VALUE for nulls, or the actual value if not null.
3) Use a DataTable or other System.Data object to store the information.

Solution 1 assumes the programmer that uses this class understands the rules going in and is willing to do class.property = INTEGERNULL whenever they interact with the class. I consider this not to be a graceful solution.

Solution 2 requires a lot of additional code in the get/set of the properties. Also, the code completer will display “Param1 as Object” rather than (for example) “Param1 as Integer.” This, too, seems to not be a good solution.

Solution 3 is off limits due to internal data abstraction policies.

* * * ANYONE KNOW OF A BETTER WAY * * *

Thanks!
Ben

 

[chrissie1]

why not use Nothing

Christiaan Baes
Belgium

If you want to get an answer read this FAQ faq796-2540
There's no such thing as a winnable war - Sting

 

[benvegiard]

The same scenario is true using "Nothing". You cannot assign Nothing to an integer property (or datetime property, etc)