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? It appears that some don't even agree with the above statement.

Example of some pro & con resources:

  • Could you add a link to an example of such list?
    – svick
    Feb 11, 2013 at 10:22
  • @svick: Examples added.
    – Dave New
    Feb 11, 2013 at 14:31
  • What about a Strongly-Typed Dataset?
    – JeffO
    Feb 11, 2013 at 15:14

1 Answer 1


What you mentioned about Entity Framework happens only if you're model is up to date (in data-driven design). If not, you won't get a compile-time error, and they would definitely defer to become run-time errors.

Consider this scenario. You create a database, with one table called Users which has 3 columns: Username, Password, IsActive.

You create a project, and add an Entity Framework .edmx file to it, updating it with the schema of your database. Great till here.

Now what happens if someone change the data type of the IsActive column from Boolean to int, and you don't know about it?

You simply build your project (which builds successfully) and run it, and then you get some errors.

In model-first and code-first development models, the scenario is even worst, as there is no direct and auto-generated mapping between your domain model and database schema.

Thus by the experience I've got till now, I can't say that Entity Framework definitely helps you get mapping problems at compile time. The only case it can help, is to let it generate the model itself from database, and get updated.

  • Thanks for the valid point! EF won't help you if there have be structural changes to the database, sure. But what about all the SELECT, UPDATE, INSERT and DELETE operations which we would perform in SQL? That is most likely where run-time errors would occur due to the frequency that these operations are changing.
    – Dave New
    Feb 11, 2013 at 14:47
  • @davenewza, what do you exactly mean by change in those operations? Do you mean misspelling? Or are you talking about Select command becoming Get command in the next version of SQL Specification? Feb 11, 2013 at 15:00
  • Sorry, I mean that these operations may continually be updated and changed to cater for evolving business requirements. It's very seldom that we write code and that it never gets changed down the line - in fact I have never seen this.
    – Dave New
    Feb 11, 2013 at 15:02
  • 1
    If you mean changing the hard-coded T-SQL in your Data Access Layer, then yeah, you're totally right. An strongly-typed ORM would help in that. Feb 11, 2013 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.