Utility Classes

We'll wrap up this chapter by creating a couple more utility classes that may be generally useful in application development. The first is SafeDataReader , a wrapper around any ADO.NET data reader object that automatically handles any null values that might come from the database. The second is NameValueList , which will implement a generic read-only name -value collection object that can be loaded from a database table.

SafeDataReader

Null values should be allowed in database columns for only two reasons. The first is when we care about the difference between a value that was never entered and a value that is zero (or an empty string). In other words, we actually care about the difference between "" and null , or between 0 and null . There are applications where this matters ”where the business rules revolve around whether a field ever had a value (even an empty one) or never had a value at all.

The second reason for using a null value is where a data type doesn't intrinsically support the concept of an empty field. The most common example is the SQL DateTime data type, which has no way to represent an empty date value; it always contains a valid date. In such a case, we can allow null values in the column specifically so that we can use null to indicate an empty date.

Of course, these two reasons are mutually exclusive. If we're using null values to differentiate between an empty field and one that never had a value, we need to come up with some other scheme to indicate an empty DateTime field. The solution to this problem is outside the scope of this book ”but thankfully, the problem itself is quite rare.

The reality is that very few applications ever care about the difference between an empty value and one that was never entered, so the first scenario seldom applies. If it does apply, then dealing with null values at the database level isn't an issue ”all variables in the application must be of type object , so that they can hold a null value. Obviously, there are negative performance implications here, but if the business requirements dictate that "" or 0 are different from null , then this is the answer.

For most applications, the only reason for using null values is the second scenario, and this one is quite common. Any application that uses date values, and where an empty date is a valid entry, will likely use null to represent an empty date.

Unfortunately, a whole lot of poorly designed databases allow null values in columns where neither scenario applies, and we developers have to deal with them. These are databases from which we might retrieve a null value even if we don't care about it and didn't want it. Writing defensive code to guard against tables where null values are erroneously allowed can quickly bloat our data access code and make it hard to read. To avoid this, we'll create a SafeDataReader class that will take care of these details on our behalf .

As a rule, data reader objects are sealed , meaning that we can't simply subclass an existing data reader class such as SqlDataReader and extend it. However, we can do what we did in Chapter 4 to create our SmartDate class: we can encapsulate or "wrap" a data reader object.

Creating the SafeDataReader Class

To ensure that we can wrap any data reader object, we'll be working with the root IDataReader interface that's implemented by all data reader objects. Also, since we want the SafeDataReader to be a data reader object, we'll implement that interface as well.

Tip  

Because IDataReader is a very large interface, we won't include all the code for the class in the book's text. The complete class is available in the code download associated with the book.

Create the Class

Add a new class to the CSLA project and name it SafeDataReader . Let's start with the following code:

  using System; using System.Data; namespace CSLA.Data {   public class SafeDataReader : IDataReader   {     IDataReader _dataReader;     public SafeDataReader(IDataReader dataReader)     {       _dataReader = dataReader;     }   } }  

We put the class in the CSLA.Data.SafeDataReader namespace. This helps keep the class organized within our framework.

We start by declaring that we'll implement the IDataReader interface ourselves in this class. The class also defines a variable to store a reference to the real data reader that we'll be encapsulating, and we have a constructor that accepts that data reader object as a parameter.

To create an instance of SafeDataReader , we need to start with an existing data reader object. This is pretty easy ”it means that our ADO.NET code might appear as follows :

 SafeDataReader dr = new SafeDataReader(cm.ExecuteReader); 

A command object's ExecuteReader() method returns a data reader object that we can use to initialize our wrapper object. The remainder of our data access code can use our SafeDataReader object just like a regular data reader object, because we've implemented IDataReader .

The implementation of IDataReader is a lengthy business ”it contains a lot of methods ”so we're not going to go through all of it here. However, we should look at a couple of methods to get a feel for how the thing works.

GetString

All the methods that return column data are "null protected" with code like this:

  public string GetString(int i)    {      if( _dataReader.IsDBNull(i))        return string.Empty;      else        return _dataReader.GetString(i);    }  

If the value in the database is null , we return some more palatable value ”typically, whatever passes for "empty" for the specific data type. If the value isn't null , we simply return the value from the underlying data reader object.

There really are a lot of these methods. There has to be one for each data type that we might get from the database!

GetDateTime and GetSmartDate

Most types have "empty" values that are obvious, but two are problematic : DateTime and Boolean . The former, for instance, has no "empty" value:

  public DateTime GetDateTime(int i)    {      if(_dataReader.IsDBNull(i))        return DateTime.MinValue;      else        return _dataReader.GetDateTime(i);    }  

Here, we're arbitrarily assigning the minimum date value to be the "empty" value. This hooks into all the issues that we discussed in Chapter 4, when we created the SmartDate class. We'll provide alternative methods in SafeDataReader that utilize the SmartDate class:

  public CSLA.SmartDate GetSmartDate(int i)    {      if(_dataReader.IsDBNull(i))        return new CSLA.SmartDate(false);   else        return new CSLA.SmartDate(_dataReader.GetDateTime(i), false);    }    public CSLA.SmartDate GetSmartDate(int i, bool minIsEmpty)    {      if(_dataReader.IsDBNull(i))        return new CSLA.SmartDate(minIsEmpty);      else        return new CSLA.SmartDate(_dataReader.GetDateTime(i), minIsEmpty);    }  

Our data access code can now choose either to accept the minimum date value as being equivalent to "empty" or to retrieve a SmartDate object that is more intelligent :

 SmartDate myDate = dr.GetSmartDate(0); 

or

 SmartDate myDate = dr.GetSmartDate(0, false); 

GetBoolean

Likewise, there is no "empty" value for the bool type:

  public bool GetBoolean(int i)    {      if(_dataReader.IsDBNull(i))        return false;      else        return _dataReader.GetBoolean(i);    }  

As you can see, we arbitrarily return a false value in this case. You may need to alter the return value of GetBoolean() (or indeed GetDateTime() ) to suit your specific application requirements.

Other Methods

The IDataReader interface also includes a number of methods that don't return column values, such as the Read() method:

  public bool Read()    {      return _dataReader.Read();  } 

In these cases, we simply delegate the method call down to the underlying data reader object for it to handle. Any return values are passed back to the calling code, so the fact that our wrapper is involved is entirely transparent.

The SafeDataReader class can be used to simplify our data access code dramatically, anytime we're working with tables in which null values are allowed in columns where we really don't want them or care about them. If your application does care about the use of null values, you can simply use the regular data reader objects instead.

We'll make use of SafeDataReader in Chapter 7 as we implement our business objects.