Nullable Types as Property

Question

Is it ok to construct my object entities with this type?

   public class Patient
   {
        public Datetime? AdmissionDate { get; set; }
        public double? AdmissionFee { get; set }
        public int? RoomNumber { get; set }
    }

WHat is the drawback if I implemented this in all my entities, because recently, I always encounter situation where I really need to set the value to null, specially in DateTime. My current solution was put DateTime.MinValue when fetching null datetimes record from the database, and when Im displaying the result to Ui, I just check it like this.

    if (patient.AdmissionDate == Datetime.MinValue)
    {
         DisplayAdmissionDate(string.empty)
    }
    else
     {
        DisplayAdmissionDate(patient.AdmissionDate)
    }

Yes, in gridview, I have to put it on the Databound event, so when i have million data to display, I thought checking each of the datetime's each loop was not the most elegant way so, to this problem, I find this ? type where I can put null values, and I'm planning to ?ed all my properties, so in the future, putting null values to this value types will not be a problem. Any advise guys? TIA

Answer 1

The object always should contain at least one non-nullable ValueType as a Primary Key. In your case, you should use

public int ID {get;set;}

Doing this, you can always identify an object. The rest of the properties can be nullable.

The check for nullable is perfectly fine, unless the GridView can detect that on its own already. Nullable types were introduces exactly for that purpose, allowing a ValueType to have null as a value. The performance aspect should be minimal isn't complex in any way and optimizing it would be a case of premature optimization.

If you want to know more about the implementation of Nullable<T>, have a look here (sadly, the original page currently is down, so the webcache version has to be sufficient. The code is readable though, just the blogpost is abit broken).

Answer 2

The downside with nullable types is that you must always check to see wether they have a value or not before operating on them...

if(AdmissionFee.HasValue) total += AdmissionFee;

instead of just

total += AdmissionFee;

Answer 3

You may get problems with data binding, I don’t think WinForms will cope well as it predates nullable types.

If an item can be null in real life then a nullable type is a good solution as it makes the clear. However don’t just use them for the sake of it.

Answer 4

This is one of those situations where no single, dogmatic answer covers all cases.

You can’t get away with always using nullable types (or always avoiding them). You should think about each case and use the one that you actually need.

You mentioned that you often needed a nullable DateTime. So why can’t you just use a DateTime? in those cases? This should be an independent consideration from all other fields, especially ints.

The null value in nullable types is intended to mean the value is something like unspecified, unavailable or unknown. There are many situations where this concept exists (e.g. users on a website may or may not specify their date of birth, so that should be a DateTime?), but there are also many situations where this concept makes no sense (e.g. the number of items in a List — if the List itself isn’t null, then clearly it has a definite number of items, so that should be int, not int?).