Last post Nov 08, 2020 09:29 PM by DA924
Nov 08, 2020 01:40 PM|4M-Tech|LINK
My data access choices for my web projects
If I choose the first option (ADO.NET + stored procedures), would I be missing some benefits?
Appreciate all your advice.
Nov 08, 2020 04:46 PM|Mikesdotnetting|LINK
Before learning how to use an ORM like EF or Dapper, I think you should spend a bit of time learning about the problems that they are intended to solve.
The biggest problem that you have when working ADO.NET is that the data containers that it provides (DataReaders and DataTables) are not strongly typed. So it is very easy to mistype a column name when using a reader or table, and end up with runtime errors
complaining that the index is out of bounds etc. Or you might change a column or table name in your DB and then find that your datareaders still reference the old column name.
Dapper doesn't solve these problems because it doesn't generate SQL based on the column and table mappings, but EF does. Both of them enable you to work with data as strongly typed objects instead of string or numeric indexers (rdr["FirstName"] etc).
If you plan to stick with your own SQL (as stored procs or inline) I would recommend that you look at Dapper rather than EF (https://www.learndapper.com). If you find that you prefer to work with data as objects
having done that, then you might want to look at EF Core out of interest, if nothing else (https://www.learnentityframeworkcore.com)
Nov 08, 2020 04:47 PM|mgebhard|LINK
EF populates models while ADO.NET you'll need to write code to populate models.
Nov 08, 2020 09:29 PM|DA924|LINK
f I choose the first option (ADO.NET + stored procedures), would I be missing some benefits?
IMHO, you need to learn the basics of ADO.NET first before anything else.
You write the words ADO.NET. But do you really know what ADO.NET is about, because there are books that cover ADO.NET?
After all, it's called the ADO.NET Entity Framework, and EF uses ADO.NET components.