How To Manually Create A Typed DataTable in C-Sharp(C#)

Introduction
I am writing this article because there is not a lot of information on the web about using the DataTable.GetRowType() method, and the code examples that I found were plain wrong or incomplete. Furthermore, there doesn't appear to be any automated tools for creating just a typed DataTable--instead there are tools for creating a typed DataSet. In the end, I ended up creating a typed DataSet simply to figure out what I was doing wrong with my manually created typed DataTable. So this is a beginner article on what I learned, and the purpose is to provide an example and correct information as resource for others. I don't provide a tool for creating a type DataTable, that might be for a future article.

What Is A Typed DataTable?
A typed DataTable lets you create a specific DataTable, already initialized with the required columns, constraints, and so forth. A typed DataTable typically also uses a typed DataRow, which lets you access fields through their property names. So, instead of:

DataTable personTable=new DataTable();
personTable.Columns.Add(new DataColumn("LastName"));
personTable.Columns.Add(new DataColumn("FirstName"));

DataRow row=personTable.NewRow();
row["LastName"]="Clifton";
row["FirstName"]="Marc";
Using a typed DataTable would look something like this:

PersonTable personTable=new PersonTable();
PersonRow row=personTable.GetNewRow();
row.LastName="Clifton";
row.FirstName="Marc";
The advantage of a type DataTable is the same as with a typed DataSet: you have a strongly typed DataTable and DataRow, and you are using properties instead of strings to set/get values in a row. Furthermore, by using a typed DataRow, the field value, which in a DataRow is an object, can instead be already cast to the correct type in the property getter. This improves code readability, eliminates the chances of improper construction and typos in the field names.

Creating The Typed DataTable
To create a typed DataTable, create your own class derived from DataTable. For example:

public class PersonTable : DataTable
{
}
There are two methods that you need to override: GetRowType() and NewRowFromBuilder(). The point of this article is really that it took me about four hours to find out that I needed to override the second method.

protected override Type GetRowType()
{
return typeof(PersonRow);
}

protected override DataRow NewRowFromBuilder(DataRowBuilder builder)
{
return new PersonRow(builder);
}
That second method is vital. If you don't provide it, you will get an exception concerning "array type mismatch" when attempting to create a new row. It took me hours to figure that out!

Creating The Typed DataRow
Next, you need a typed DataRow to define the PersonRow type referenced above.

public class PersonRow : DataRow
{
}
Constructor
The constructor parameters, given the NewRowFromBuilder call above, is obvious, but what is less obvious is that the constructor must be marked protected or internal because the DataRow constructor is marked internal.

public class PersonRow : DataRow
{
internal PersonRow(DataRowBuilder builder) : base(builder)
{
}
}
Filling In The Details
Next, I'll show the basics for both the typed DataTable and DataRow. The purpose of these methods and properties is to utilize the typed DataRow to avoid casting in the code that requires the DataTable.

PersonTable Methods
Constructor
In the constructor, we can add the columns and constraints that define the table.

public class PersonTable : DataTable
{
public PersonTable()
{
Columns.Add(new DataColumn("LastName", typeof(string)));
Columns.Add(new DataColumn("FirstName", typeof(string)));
}
}
The above is a trivial example, which doesn't illustrate creating a primary key, setting constraints on the fields, and so forth.

Indexer
You can implement an indexer that returns the typed DataRow:

public PersonRow this[int idx]
{
get { return (PersonRow)Rows[idx]; }
}
The indexer is implemented on the typed DataTable because we can't override the indexer on the Rows property. Bounds checking can be left to the .NET framework's Rows property. The typical usage for a non-typed DataRow would look like this:

DataRow row=someTable.Rows[n];
whereas the indexer for the type DataRow would look like this:

PersonRow row=personTable[n];
Not ideal, as it looks like I'm indexing an array of tables. An alternative would be to implement a property perhaps named PersonRows, however this would require implementing a PersonRowsCollection and copying the Rows collection to the typed collection, which would most likely be a significant performance hit every time we index the Rows collection. This is even less ideal!

Add
The Add method should accept the typed DataRow. This protects us from adding a row to a different table. If you try to do that with a non-typed DataTable, you get an error at runtime. The advantage of a typed Add method is that you will get a compiler error, rather than a runtime error.

public void Add(PersonRow row)
{
Rows.Add(row);
}
Remove
A typed Remove method has the same advantages of the typed Add method above:

public void Remove(PersonRow row)
{
Rows.Remove(row);
}
GetNewRow
Here we end up with a conflict if we try to use the DataTable.NewRow() method, because the only thing different is the return type, not method signature (parameters). So, we could write:

public new PersonRow NewRow()
{
PersonRow row = (PersonRow)NewRow();

return row;
}
However, I am personally against using the "new" keyword to override the behavior of a base class. So prefer a different method name all together:

public PersonRow GetNewRow()
{
PersonRow row = (PersonRow)NewRow();

return row;
}
PersonRow Properties
The typed DataRow should include properties for the columns defined in the PersonTable constructor:

public string LastName
{
get {return (string)base["LastName"];}
set {base["LastName"]=value;}
}

public string FirstName
{
get {return (string)base["FirstName"];}
set {base["FirstName"]=value;}
}
The advantage here is that we have property names (any typo results in a compiler error), we can utilize Intellisense, and we can convert the object type here instead of in the application. Furthermore, we could add validation and property changed events if we wanted to. This might also be a good place to deal with DBNull to/from null conversions, and if we use nullable types, we can add further intelligence to the property getters/setters.

PersonRow Constructor
You may want to initialize the fields in the constructor:

public class PersonRow : DataRow
{
internal PersonRow(DataRowBuilder builder) : base(builder)
{
LastName=String.Empty;
FirstName=String.Empty;
}
}
Row Events
If necessary, you may want to implement typed row events. The typical row events are:

ColumnChanged
ColumnChanging
RowChanged
RowChanging
RowDeleted
RowDeleting
I'll look at one of these events, RowChanged, to illustrate a typed event.

Defining The Delegate
First, we need a delegate of the appropriate type:

public delegate void PersonRowChangedDlgt(PersonTable sender, PersonRowChangedEventArgs args);
Note that this delegate defines typed parameters.

The Event
We can now add the event to the PersonTable class:

public event PersonRowChangedDlgt PersonRowChanged;
Defining The Event Argument Class
We also need a typed event argument class because we want to use our typed PersonRow:

public class PersonRowChangedEventArgs
{
protected DataRowAction action;
protected PersonRow row;

public DataRowAction Action
{
get { return action; }
}

public PersonRow Row
{
get { return row; }
}

public PersonRowChangedEventArgs(DataRowAction action, PersonRow row)
{
this.action = action;
this.row = row;
}
}
Overriding The OnRowChanged Method
Rather than add a RowChanged event handler, we can override the OnRowChanged method and create a similar pattern for the new method OnPersonRowChanged. Note that we still call the base DataTable implementation for RowChanged. These methods are added to the PersonDataTable class.

protected override void OnRowChanged(DataRowChangeEventArgs e)
{
base.OnRowChanged(e);
PersonRowChangedEventArgs args = new PersonRowChangedEventArgs(e.Action, (PersonRow)e.Row);
OnPersonRowChanged(args);
}

protected virtual void OnPersonRowChanged(PersonRowChangedEventArgs args)
{
if (PersonRowChanged != null)
{
PersonRowChanged(this, args);
}
}
Note that the above method is virtual, as this is the pattern for how events are raised in the .NET framework, and it's good to be consistent with this pattern.

Now, that's a lot of work to add just one typed event, so you can see that having a code generator would be really helpful.

Using The Event
Here's a silly example to illustrate using the typed DataTable and the event:

class Program
{
static void Main(string[] args)
{
PersonTable table = new PersonTable();
table.PersonRowChanged += new PersonRowChangedDlgt(OnPersonRowChanged);
PersonRow row = table.GetNewRow();
table.Add(row);
}

static void OnPersonRowChanged(PersonTable sender, PersonRowChangedEventArgs args)
{
// This is silly example only for the purposes of illustrating using typed events.
// Do not do this in real applications, because you would never use this Changed event
// to validate row fields!
if (args.Row.LastName != String.Empty)
{
throw new ApplicationException("The row did not initialize to an empty string for the LastName field.");
}
}
}

This however illustrates the beauty of a typed DataTable and typed DataRow: readability and compiler checking of proper usage.

Conclusion
Hopefully this article clearly illustrates how to create a typed DataTable manually. The "discovery" that I made (that I couldn't find anywhere else on the Internet) is that, when you override GetRowType(), you also need to override NewRowFromBuilder().