I received an interesting question today that I started to answer in email, then realized it would make a good blog post. It went something like…"Do you know if EF4 addresses the Bob Beauchemin’s criticism in his “LINQ to SQL and Entity Framework: Panacea or evil incarnate?” blog entries?"
First off, the series was not a blanket criticism of LINQ to SQL or Entity Framework, but a set of concerns, purely from a "database programmer's" point of view. That is, I'm comfortable with programming languages that are SQL-based and also languages that "are not SQL", like C#, and also comfortable with LINQ (which can use a syntax that's almost a dead-ringer for SQL). After examining the concerns, I dismissed some of them as unwarrented. I also didn't attempt to critique object-orientation or object-relational mapping in general, though some of the concerns are intrinsic to mappers in general (e.g. the existing of a code generator that generates SQL from LINQ or ESQL code). While we're on the subject of code generators, bear in mind that both L2S and EF support stored procedures and "store queries" and so use of the L2S or L2E/ESQL language is, techincally, optional.
So how does EF4/L2S4 change the game?
1. EF4 has fixed some of the “plan cache pollution” problems I referred to, but, in order to avoid plan cache pollution you must use parameterized queries in you L2E or ESQL code. There were other SQL generator related enhancements too. See these two blog entries by the team.
2. The best practice of “always get an anonymous type with only the columns you need” unless you REALLY need a whole object instance still holds.
3. There’s still no way to do bulk updates or deletes, but there are various workarounds for this.
4. It's still a best practice to limit the number of levels of "Included" objects in your L2E code; the code generator does best when you limit the number of levels of objects returned in a single database call. In EF4, lazy loading is the default, but you can override this by using the ObjectContext.ContextOptions.LazyLoadingEnabled property.
5. It’s easier to use stored procedures in EF4 than EF1 (i.e. the added designer support).
6. There’s more ways to write functions in the EDMX file in EF4. Functions can be written in the CSDL, MSL, or SSDL.
However, EF4 devoted a significant number of cycles to pleasing the traditional O/R mapping folks, providing persistance ignorance, foreign keys in the model, support for test-driven development, and alternate development styles like POCO, code first, etc. So some of the database afficianado features like:
1. SQL Server table-valued function support in the SqlClient provider that supports EF.
2. UDT (including types like SQL Server's spatial and hierarchyid types, that are built on the SQLCLR UDT architecture) support.
3. Exposing database defaults and constraints in the model.
didn't make it in EF4. Maybe next time.
As always, MHO.