Reputation: 1301
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
Upvotes: 4
Views: 56360
Reputation: 9890
According to https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/property?redirectedfrom=MSDN:
AVOID throwing exceptions from property getters.
Since SomeNullableProperty.Value
can throw a NullReferenceException
, I'd say you should at least have logic in your getter to make sure there's a default value.
Upvotes: 0
Reputation: 66584
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 int
s.
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?
).
Upvotes: 7
Reputation: 51927
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.
Upvotes: 0
Reputation: 13672
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;
Upvotes: 0
Reputation: 61467
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).
Upvotes: 2