The Entity Framework team at Microsoft has been extremely busy this past year to get a new version of the Entity Framework out the door. The first release (which shipped last summer with .NET 3.5 SP1) generated a fair amount of criticism, especially because it lacked many features present in LINQ to SQL, such as POCO (Plain Old CLR Objects) support, and required developers to write excessive amounts of code to deal with things like concurrency and n-tier scenarios.
In response, the EF team published an Entity Framework Design Blog, soliciting feedback from the community on critical design decisions. The team has also published a series of posts on new features on the ADO.NET Team Blog. We now have the first CTP of EF4 and the MSDN documentation is online.
EF4 comes with a boat load of features, so many in fact that it\’s hard to know where to begin! To help break them down, I have compiled a top-ten list of EF4 features. These are listed in relative order of importance.
-
Define your own objects that are completely decoupled from persistence concerns.
-
Create customized code generation templates (for example, POCO classes).
-
Load related entities automatically on-demand.
-
Different options for tracking changes to entities.
-
Propagate entity changes across service boundaries for batch updates.
-
The tools fix up entity names in case database tables are in plural form (Northwind!).
-
Create an entity model and generate the database from it.
-
Create classes without a model.
-
Have more control over storage, conceptual and mapping schemas.
-
Miscellaneous Improvements
Create complex types in your model.
b. Foreign Keys
Optionally include foreign keys in your model.
c. LINQ to Entities Functions and Operators
Call database, conceptual and model-defined functions from L2E queries.
d. Testability Improvements with IObjectSet<T>
Test-driven development is easier now.
e. T-SQL Readability and Performance
Generated SQL is faster, simpler and easier to read.
Hats off to the EF team for responding to almost all our requests. Mapping multiple stored procedure results to complex entities is still not supported, but there has to be something for the next version. 🙂
Tony Sneed's Blog 
Great work by EF Team and ofcourse great work by Tony to categorise the top 10 New features in EF. This EF4 is going to be mind blowing STUFF !!!
Hi,
Great post.By the way all the links seems to be broken.
The links are working now. 🙂 My blog had been hacked and I couldn’t log in to easily edit the post. But that’s corrected now and things are back to normal.
Pingback: Tony and Zuzana’s World » Who is Improving LINQ to SQL? Plinqo by Code Smith!
Pingback: Learning resources for Entity Framework 4.0 new features « Bogdan Brinzarea’s blog
After installing SP 3 for XP the EF designer won’t load, what can I do?
Thanks
Mike
Hi All,
One thing I was hoping to see on the top 10 list was an improvment to how EF copes with large models.
We have 600+ tables and don’t want to have all 600 in the one model. It would make sense to break our model into multiple sub-models and have a common model for shared tables such as a Users table which would be used in most sub-models. But you can’t reference models in your models. The work-around for this is to add the common tables to each sub-model. If a common table changes you need to update it in each model. Another work-around was to manually hack the XML files but this detracts from the user experience.
Does EF4 improve support for this scenario?
Cheers,
Sandy.
@Sandy: There is a “using” element which can allow you to share entities in the CSDL between models (perhaps what you refer to as “manually hack” the XML files. Sadly, doing this will disable the designer support, forcing you to hand edit the XML for any future changes — which is not something I recommend. So in the meantime, the recommended approach is to duplicate common tables among the various sub-models, meaning you would have to update all the models if there is a change in one of the common tables.
So the answer is that EF4 does not offer any additional support in the area of large models. For a database with 100 or more tables, you should definitely use multiple models, both for performance and maintainability. For more information on this topic, see
http://blogs.msdn.com/adonet/archive/2008/11/24/working-with-large-models-in-entity-framework-part-1.aspx
http://blogs.msdn.com/adonet/archive/2008/11/24/working-with-large-models-in-entity-framework-part-2.aspx