Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

share|improve this question
    
Could you add a link to an example of such list? –  svick Feb 11 '13 at 10:22
    
@svick: Examples added. –  davenewza Feb 11 '13 at 14:31
    
What about a Strongly-Typed Dataset? –  JeffO Feb 11 '13 at 15:14
add comment

1 Answer

up vote 3 down vote accepted

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.

share|improve this answer
    
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. –  davenewza Feb 11 '13 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? –  Saeed Neamati Feb 11 '13 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. –  davenewza Feb 11 '13 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. –  Saeed Neamati Feb 11 '13 at 15:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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