C# in Depth

114 CHAPTER 4 Saying nothing with nullable typesyou often care about having the whole range of possible bit patterns available as realvalues, whereas with reference types we’re happy enough to lose one potential valuein order to gain the benefits of having a null value.That’s the usual situation—now why would you want to be able to represent nullfor a value type anyway? The most common immediate reason is simply because databasestypically support NULL as a value for every type (unless you specifically make thefield non-nullable), so you can have nullable character data, nullable integers, nullableBooleans—the whole works. When you fetch data from a database, it’s generallynot a good idea to lose information, so you want to be able to represent the nullity ofwhatever you read, somehow.That just moves the question one step further on, though. Why do databasesallow null values for dates, integers and the like? Null values are typically used forunknown or missing values such as the dispatch date in our earlier e-commerceexample. Nullity represents an absence of definite information, which can be importantin many situations.That brings us to options for representing null values in C# 1.4.1.2 Patterns for representing null values in C# 1There are three basic patterns commonly used to get around the lack of nullablevalue types in C# 1. Each of them has its pros and cons—mostly cons—and all of themare fairly unsatisfying. However, it’s worth knowing them, partly to more fully appreciatethe benefits of the integrated solution in C# 2.PATTERN 1: THE MAGIC VALUEThe first pattern tends to be used as the solution for DateTime, because few peopleexpect their databases to actually contain dates in 1AD. In other words, it goes against thereasoning I gave earlier, expecting every possible value to be available. So, we sacrificeone value (typically DateTime.MinValue) to mean a null value. The semantic meaning ofthat will vary from application to application—it may mean that the user hasn’t enteredthe value into a form yet, or that it’s inappropriate for that record, for example.The good news is that using a magic value doesn’t waste any memory or need anynew types. However, it does rely on you picking an appropriate value that will never beone you actually want to use for real data. Also, it’s basically inelegant. It just doesn’tfeel right. If you ever find yourself needing to go down this path, you should at leasthave a constant (or static read-only value for types that can’t be expressed as constants)representing the magic value—comparisons with DateTime.MinValue everywhere,for instance, don’t express the meaning of the magic value.ADO.NET has a variation on this pattern where the same magic value—DBNull.Value—is used for all null values, of whatever type. In this case, an extra valueand indeed an extra type have been introduced to indicate when a database hasreturned null. However, it’s only applicable where compile-time type safety isn’timportant (in other words when you’re happy to use object and cast after testing fornullity), and again it doesn’t feel quite right. In fact, it’s a mixture of the “magic value”pattern and the “reference type wrapper” pattern, which we’ll look at next.Licensed to Rhona Hadida