Geek Answers Handbook

Best C # generics class to replace DataTable as a collection?

I am trying to bring an obsolete C # .NET 1.1 application into the modern era. We use DataTables for our collections of what could be business objects.

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

+4
source share
4 answers

If I am reading your question correctly, you ask which container will simply store a list of your business objects, and then allow just listing through a collection or selecting through an index.

Ok, I would consider searching in List <>

where your methods will accept either IList <> (to access the index) or IEnumerable <> (use the foreach loop in the collection)

eg

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

now I can pass in any container that uses the IEnumerable <> interface, including List <> and a normal array

Example

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

sample n-tier application with buiness objects

NTN

bones

+7
source

Instead of dropping the DataSet / DataTable API, why not subclass DataTable and DataRow into types appropriate for your business logic?

Support for the DataRow and DataTable subclass objects is excellent. You will get strong text input in your new code along with backward compatibility for your old code. In addition, you can enter business logic wherever you need / need.

+3
source

If you are used to DataTable , you are supposedly used to tracking changes and maintaining the storage that adapters (etc.) bring. In which case did you consider LINQ-to-SQL and / or Entity Framework? They support rich chaneg tracking and auto save, offering various other DAL uses such as compound queries and all other LINQ benefits.

Definitely worth the investigation.

Note that switching to typed POCO objects (i.e. not a DataRow and a subclass) is still a big deviation, so this will not be a simple change. If you don't have time for major changes, it would be pragmatic to stick with a DataTable (probably typed).

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

+2
source

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

The above solutions lose a lot of things for you, including tracking changes, if only what you are looking for - to deviate to a large extent. LINQ to SQL, Entity Framework, etc. They provide change tracking, but within the "Unit of work" mechanism for connecting to db instead of placing the Unit of work tracking directly on your objects, as with DataRow.

I hope you do not just change your application to the modern era, and you have some advantages that you are trying to get for the functions that you pass and the efforts that you spend?

By the way, all this assumes that you are using Typed DataSets ... Untyped DataSet objects seem to be silly, in my opinion, for most purposes.

+1
source

More articles:


All Articles