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.

Does Entity Framework mean you might never have to use SQL or design database tables again?

Is this what "persistence ignorance" means?

I am new to EF and ORMs in general, and I would like to understand how much of it is hype and how much is reality.

share|improve this question

4 Answers 4

Definitely no because EF is heavily dependent on correct database design. It usually fails expectation where used with legacy or incorrectly designed databases. Also full power of EF can be unleashed only when combining with direct SQL.

Each abstraction shields you from some implementation. ORM is abstraction of data access but only coding monkeys are shielded from these details as well. Developers must understand concepts running under the hood of abstraction to know how to use them correctly.

share|improve this answer

+1 to maple_shaft. I would add that even when you are using the (much balyhooed) EF Code First you are still modelling tables. It's been more than 20 years that people have used modelling and CASE tools that put an abstraction layer between themselves and the DDL script that builds their tables. That doesn't change the fact that they need to know how to design tables properly.

share|improve this answer

Actually no. The basic database concepts will apply and you have to know some basic rules of what databases can do or else you'd face significant performance issues.

Entity Frameworks are useful to handle the conversion of mapping data from database records into objects. This allows developers to not have to deal with creating data access objects because the framework does it for you already.

So this will do quite a bit for developers especially when persisting data.

Looking up data can be performed with entity frameworks as well, but lookups are not always best done with just entity frameworks alone because if done improperly you will have memory issues when someone decides to load up the entire database into memory. Or I/O issues if someone decides to do queries inside another query. (Those two are the common performance issues I see when I review other people's code).

Sometimes it may be that you need raw SQL, stored procedure or a database view in order to get the best performance/maintainability ratio.

As such a good DBA is a valued resource. Although I try to relegate the database to be just a data store, they still need to perform tuning so the proper indices and storage allocation is done correctly.

One thing that entity frameworks allow me to do is to talk about objects and tables with the DBA in logical terms rather than physical terms. It allows application development and database to form a contract in the form of an Object Relational diagram that they agree to reduce the chances of defects (or at the very least quickly assign the blame).

share|improve this answer
    
+1 for EF is an ORM and as such it is good for simple reads but potentially a big problem for complex (i.e. real world) reads. –  Joel Brown Dec 5 '11 at 13:28
    
I don't understand how it could get the SQL wrong. If the compiler understands your objects how could it not translate it into SQL. I reckon I could code it myself. ;) –  CJ7 Dec 5 '11 at 13:33
2  
@CraigJ : in most cases it will generate valid SQL which will get you the result set. But, because we are dealing with a generic sql generator, it will not generate the optimal sql statements for the problem in many cases. 99.99% of the time that doesn't matter. That other .01% of the time it really, really, really matters. –  Wyatt Barnett Dec 5 '11 at 13:55
    
@CraigJ On top of what Wyatt Barnett pointed out, many times a small mistake in your data model, a disconnect between your actual data model and schema (usually when generating model from existing schema, not the other way around), or a hard to spot EF query bug, can sometimes require deep inspection of generated SQL to quickly locate the problem. Sometimes to avoid face-to-keyboard bouts of extreme frustration, it is easier to turn debug logging on and copy SQL directly into your database query editor. I can't tell you how many times I have had a WTF OF COURSE moment of clarity from this. –  maple_shaft Dec 5 '11 at 14:20

EntityFramework is a great tool, but like any great tool you would do yourself a great disservice to not understand the inner workings of how it translates a data model into a database schema, and also how it translates its own queries into SQL.

Everything works great until something goes wrong, then you are looking in log files trying to decipher the generated SQL to figure out where the bug is. Good luck with that if you do not have an understanding of the schema or SQL.

The term "Persistence Ignorance" is heralded as a good thing, but only in terms of creating loose coupling from your data access layer. Your business logic and presentation layers should be "Persistence Ignorant", not the developer!

Only in the US is Ignorance celebrated as a good thing ;)

share|improve this answer
    
An example of your second paragraph - We had a stored proc on a "black box" legacy database that was timing out under certain circumstances. It took hours to resolve the problem since this usage was so well buried (in this case in CSLA code, but I suspect EF would be similar). Then we had to locate someone with permission to edit the SP. Bottom line is that generated code can mask problems if one isn't careful –  jfrankcarr Dec 5 '11 at 14:34
1  
+1. Over in the Java space, we have TopLink and Hibernate which predate EF by a few years; they absolutely haven't invalidated any SQL knowledge. They've also proven not to be a silver bullet, some problems are better handled with plain SQL or one of the NoSQL datastores. –  Barend Dec 5 '11 at 14:36

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.