✅ EF Core "Disconnected" Architecture Vs Ado.NET
Hello guys, can someone explain how EF core works under the hood please. I read that it just loads data in memory, everything is done in memory and all changes are made to the database when we use method like
SaveChanges().
But it may happen we don't need that method either like when we use the ExecuteDelete or ExecuteUpdate (I think, don't know how this works though). I was wondering how is this different from ADO.Net; in ADO.Net we have a choice of connected and disconnected architecture? Like I know we can use DbSet I think to load entire entity in it, then work from that.
I would really appreciate if someone can clarify how both the EF Core and ADO.Net architecture works :C9 Replies
EF's database connections are abstracted away from you, they're pooled and reused as necessary
i don't know exactly what you mean by "everything is done in memory," as much is done in memory as you would with ADO.NET and manually mapping to C# objects
EF has a change tracker which allows it to automatically determine what you did to tracked objects and generate appropriate SQL to make those changes in the database
oh, I thought, we were modifying the database directly rather than using mapped objects
The entire point of EF is to map objects. It is an ORM. Object Relational Mapper.
ADO.NET is the common denominator, it's just how you access databases in C#
EF is a bunch of extra stuff built on top of that to make your life easier so you don't have to implement it yourself
you can reimplement the entirety of EF in your own program using just ADO.NET if you wanted, but there would be no point because EF and other flavors of ORM already exist
dapper is also a layer on top of ADO.NET, albeit a much thinner one
yeah I see, is ADO.Net considered an ORM?
no
it has no functionality to map between raw SQL data and C# objects (besides primitives)
yeahh I see, it's clearer now
Other than Typed data sets. Never use those. Forget I said anything.
Noted, thanks guys !