...that is the question.
If Shakespeare knew what a Null value was I am pretty sure he would have replaced Be with Null. Maybe he did know? Am I being presumptuous?
A Null can be a double edged sword. On the one hand it can be awesome for a database. On the other hand when you are talking to a database (through EF for example) it can be 50%(ish) more effort.
Allow me to explain. I work with a very good friend/colleague and he has historically used Entity Spaces. Nothing wrong with that, it has served him well.
However, on my side it can be pain. I work more on the front end and also REST api's integrating with the solid server work he does.
Trouble is that every time a new field is introduced that allows nulls (or even a field that has been there since the initial design) I end up having to cater for an additional case. Everything seems to come across from Entity Spaces allowing a null value when wrapped in a VB.Net API (maybe that is the problem).
Because it allows nulls I need to write the following code, in the case of an object with a Boolean value that I wrap to send across a REST API (I wrap it to only send the data I need):
IsDefault = (bool)(report.IsDefault??false)
, SortOrder = ((bool)(report.IsDefault ?? false))==true?999999:(int)report.DisplayOrder
For the IsDefault field I need to check for a Null value first with the ?? operator. With the SortOrder field I want to always push whatever is a IsDefault value to the end of the list.
Now if that field did not allow null values it would either have to be True or False (and that is my preferred approach with database design).
In that case the above code could be written as follows:
IsDefault = report.IsDefault
, SortOrder = report.IsDefault==true?999999:(int)report.DisplayOrder
I know, not the end of the world but every little bit counts.
In the case of Entity Spaces (I think) I also have to Cast report.DisplayOrder to an Int even though I know it won't be null...it just comes across as a Nullable int so I am forced to Cast it.
It's the little things that count they say and it's this kind of stuff that can be the difference between an app that works 100% of the time and one that fails when you least expect it UNLESS you resort to some defensive coding like above.