DataTables are old fashioned?

Question

I am a young developer and don't really know many different ways to accessing databases and get data out of them. One of the ways I know is to use DataAdaptor with SQLcommand with Stored Procedure provided by database team to connect database and fill the data into DataTable. Then I use the datatable for processing, or bind it to gridview, etc for display purpose.

But when the reviewer reviewed my code, he said datatable is very old fashioned way. He said he rather use objects or something but I have no clue.

So is there better (or modern) way of connecting databases, and get data out of them? This is a generic question and should not really matter with what my program really does.

Answer 1

They were a stupid idea at .NET 1.0 time when the Java world already was using ORM's for years. They were a stupid idea when ADO (not ADO.NET) was released and ORM's were already in use in the Java world already and I used one with Visual Basic (not .NET).

Learn proper OO programming. Anyone using Datasets pretty much shows he has only seen the MS "how to make a UI fast" example and not ever learned trpoper object oriented programming practices.

I would NOT call a 15 years established Technology "modern".

For example, you should KNOW about LINQ. Entity Framework - both are part of the .NET Framework ans that for some time now (since 4.0).

This is not about "Age" it is about knowing what you do. And reading the documentation ONCE. When a "Young cook" only knows pepper he is not a cook, he is a one trick Pony. A "yount" (not Trainee) .NET developer who has no idea about all ways to get data out of the atabase is not a .net developer - because he misses reading the documentation ONCE. Asking about Details is ok - but not having heard of Entity Framework is... well, somoene who never read the documentation.

And again. ORM's are not new. They existe in .NET 1.0 time, they existed in old Visual Basic time.

Answer 2

Your colleague is probably well versed in ORMs like nHibernate and Entity Framework, which provide an object-oriented abstraction over your database.

Object relational mappers perform a lot of the "glue" tasks safely and automatically. Decent enough example of this are database relationships, etc.

In the MVC space, it's common for the objects that are presented to the server to have no information about the underlying data access structure.

I still use DataTable in some very limited situations. I suppose my key concerns are:-

• Very generic solution. Not domain specific.

Contrast this with a purpose-built class aimed at performing a specific job.

• A lot of coupling, a lot of error checking, or both.

Oftentimes, you'll want to use your DataTable to populate something else. To do this properly, you'll need to check for NULLS, etc, usually with something like:-

string thing = (row["Thing"] == DBNull.Value ) ? string.Empty : (string)thing;

It's onerous, time-consuming and error prone.

Mostly though, it's an artefact from the days when people would pull directly from a DB and blat it on a webpage. Today, there are several layers of abstraction in between with n-tier products, and DataTable is a reasonably poor substitute for the bells and whistles you get from an ORM.