When I read pro and con lists of using Entity Framework (or any modern ORM really), I'm surprised that the following point doesn't arise (self quote):
Using strongly-typed domain entities allows for type checking at
compile-time which essentially performs a verification of all your
database operations. This is something that is not possible with
ADO.NET (whether using inline SQL or stored procedures).
For me, this is one of the biggest advantages of using an ORM. An issue that I come across regularly when dealing with ADO.NET based applications are the run-time errors from SQL. Static checking completely eliminates this.
Could anyone elaborate as to why this isn't hugely relevant to many developers?
Oh it's great.
It's also not free. EF is essentially built on top of ADO.net, it just uses reflection to convert back-and-forth between strongly typed classes and the actual column names. This is fine if your recordset is fairly small, but it's very noticeable when you start dealing with larger sets of data. Generally this extra lag time isn't important because if, say, the DB takes two seconds to pull the data up to begin with, what difference does an extra millisecond (or even a second) make. But there are situations where speed is critically important, and in those situations you pretty much have to write your own constructs using raw ADO.
The same question was asked here. It includes some good answers.
Programmers.stackexchange.com was a more appropriate place to ask the question.