Best c# generics class for replacing DataTable as collection?

Question

I'm trying to bring a legacy C# .NET 1.1 application into the modern era. We use DataTables for our collections of what could have been business objects.

Given that most of the code thinks it is talking to the interface of a DataRow, what generic collection would make for the least painful transition?

Answer 1

Instead of changing away from the DataSet/DataTable APIs, why not subclass DataTable and DataRow into types suitable for your business logic?

The support for subclassed DataRow and DataTable objects is superb. You'll get the strong typing you want in your new code, along with the backwards compatiblity for your old code. Additionally you can inject business logic wherever you need/want it.

Answer 2

Hi Mathew.

if im reading your question rightly, you are asking for which container will just store a list of your Business objects and then allow you to just enumerate through the collection, or select via an index.

well I would consider looking into the List<>

where you methods would accept either IList<> (to access the index) or IEnumerable<> (to use a foreach loop on the collection)

for example

private void PrintAll<T>(IEnumerable<T> items)
{
    foreach(T item in items)
        Console.WriteLine(item.ToString());
}

now i can pass in any container which uses the IEnumerable<> interface, including List<> and the normal array

example

List<Person> people = new List<Person>();
//add some people to the list
PrintAll<Person>(people);

a sample n-tier app with Buiness objects

HTH

bones

Answer 3

If you are used to DataTable, presumably you are used to the change tracking and the persistence support that adapters (etc) bring. In which case, have you considered LINQ-to-SQL and/or Entity Framework? These both support rich chaneg tracking and automated persistence, while offering various other DAL use-cases such as composable queries and all that other LINQ goodness.

Definitely worth investigation.

Note that changing to typed POCO entities (i.e. not DataRow nor a subclass there-of) is still a big deviation, so it won't be a simple change. If you haven't the time for a major change, it would be pragmatic to stick with DataTable (perhaps typed).

This will provide EntitySet<T>, IQueryable<T>, etc for you, or you can just use List<T>, Collection<T> etc for ad-hoc usage.

Answer 4

The easiest way to bring your "application into the modern era" is to simply upgrade the code from Visual Studio 2003 to 2005 or 2008. If you're looking to add behavior to your classes ("what could have been business objects") the fact that the DataSet, DataTable, and DataRow are implemented as partial classes get you that.

The solutions mentioned above lose a lot of things for you, including the change tracking, unless that's what you're looking for--to deviate in a large way. LINQ to SQL, Entity Framework, etc, all provide for change tracking, but within the Unit of Work mechanism for the connection to the db, rather than placing the Unit of Work tracking directly on your objects, as with the DataRow.

Hopefully you're not simply changing to bring your "application in to the modern era" and that you have some benefits you're trying to get for the functionality you're giving up and the effort you're spending?

By the way, this is all assuming you are using Typed DataSets... untyped DataSet objects are sort of silly, in my opinion, for most uses.