I made a project that used SQLReaders and SQLCommandswhich is the equivalent of JDBC in Java. However, there seems to be a newer way, using DBContext.
Which is used in enterprise applications
It sounds like your talking about Entity Framework with the DbContext. It’s an ORM, not a low-level connection library for SQL. You can always use the low-level libraries if you want to but I’d recommend sticking with Entity Framework unless you have a use case where you absolutely need that extra control. You could also look at Dapper if you want something leaner than a full blown ORM like EF.
Those are basically different layers of the same thing. SqlDataReader, SqlCommand, etc. are parts of what used to be called ADO.NET, which is basically the low level. You can send raw SQL (including stuff like parameters) and retrieve data in various forms, such as as a table.
DbContext is a much higher-level concept from an ORM. It internally uses Sql* objects.
Which one you should use depends a lot on your use case.
Honestly, in my enterprise applications I like to have full control over my data access, so we use Ado.net (Sql Commands) and then we also use Dapper as a lightweight ORM to handle the mapping to our domain objects. It works out really well for my teams, and I have seen other teams get bitten quite a bit by using Entity. I am sure there are other things at play too, but just throwing Entity as your data access layer and calling it a day can lead to some pretty shotty solutions. In my personal experience.
I find SQL gets unmanageable personally. Also version controlling the database is a total pain. EF let’s you do it all in code which is so much easier. And the mapping is so powerful.
I recommend https://github.com/linq2db/linq2db
I have been using it for the last 10 years and currently we use it on the project with terrabytes of data.
C# devs
null reference exceptions