Still using dataset?

123 Views Asked by At

I'm a fossil I know. I still use dataset, Datatable, Datarow, Dataview and so on.

Having been around since the VB 4 days, I have seen many different data accesses come and go. I consider the dataset with associated methods and commands to be the best, probably because I know it inside and out. It is so easy to throw up a data table with different content, eg read an xml file, extract data from a data table and more.

I know I should move on to EF and EF core and I've tried many times but keep falling back. Think the dataset is faster, you have better control and can affect exactly what you want. Probably a knowledge issue on my part?

What is the situation with ADO.NET, what is the future? From what I have understood, EF and EF core are built on ADO.NET so reasonably it should remain in the future?!

Why I ask is that I ran into problem when I updated to .NET 8. The generated designer code in Visual Studio gave warnings as per this link https://github.com/dotnet/docs/issues/34893. This error was easily circumvented by setting up the dataset in code instead. Is it just that Microsoft just wants to remove formatter-based serialization and the dataset itself will remain? What do the rest of you think (or know)? and are there any others out there who still use this fossil dataaccess and like it more than EF, EFCore and other ORMs?

1

There are 1 best solutions below

2
Marc Gravell On

If it works for you, nobody is going to pry it out of your hands (at least... this week), but yes the world has moved on.

DataSet is absolutely not faster - quite the opposite: because it has to support arbitrary data shapes every query, it involves a lot of inefficiencies and indirections on data storage/access, and additional constant CPU time when accessing members by name (which is how you normally want to access them).

Tools like EF have been evolved hugely, but if you love your SQL and want to keep things simple, tools like Dapper can allow you to gain the efficiencies of a typed object model while still keeping tight control over your commands (but: without having to fight ADO.NET's command API yourself).