Entity Framework 4.0 Improvements
I am really looking forward to the next version of the Entity Framework, labeled 4.0 to match the .NET framework 4.0. Outside of the realm of the POCO designer setup, model first development, and some of those other design aspects, I'm going to look at this from the practical applications to a .NET developer, that will help to make their lives a little easier.
The first change is related to the way foreign keys appear in the designer. The previous approach of using navigation properties as the way to navigate through relationships still exists, but has changed. Every foreign key has a direct key value in the core entity, a feature that makes my life easier in many ways. Previously, LINQ to Entities liked to work with object references, so if you had an Order object, and you wanted to add a customer reference, you had to either add the customer like so:
order1.Customer = context.Customers.First(i => i.CustomerKey == 5);
Which makes a trip to the database, something I personally try to avoid. The workaround was to construct an EntityKey for the CustomerReference object, a way to map an order to a customer without the need to physically construct the customer object directly. Now, instead of having to do it this way, ADO.NET Entity Framework incorporates a feature from LINQ to SQL: direct foreign key properties. Now, to establish the customer for the order without loading the object directly, we can do:
object1.CustomerKey = 5;
Our customer is now linked and we don't need to make the round-trip to the database, because we can load the relationship value directly. This is an option that's enabled by default when you create the entity model.
Another LINQ to SQL copy is each object query has the ability to add the object directly to the collection, not requiring the use of the object context's AddToCustomer method. To add a new order to the system, we can do:
The previous context.AddToOrders methods still exist too, so your previous code will still work when upgraded to .NET 4.0.
Objects within the Entity designer can now be deleted without having to edit the XML storage definition (SSDL). Whenever the object representing the table has no mappings left with the proposed delete, the designer will give you a popup asking you if you want to delete the table in all areas of the entity definition. This was a huge pain in EF 1, and I ended up deleting the designer and recreating it all the time just to incorporate a few changes. Now, simply delete the table, click yes from the prompt, and both the object and table mappings are removed.
If you happened to merge tables into a single object, or split a table into multiple objects, the table deletion won't happen the same way. This is because the mappings are evaluated to ensure the entity has no mappings anywhere else before it's deleted. If you do perform a delete, undo actions are available too.
Entity naming can now incorporate a scheme for plurization of query names (Customers instead of Customer) within the ObjectContext and the singularization of object names for each class. This feature can be disabled when you generate the designer. Be careful and watch the name it gives though, I had a table that was suffixed with Phases and for the singular, it assigned Phasi. Either way, this can be easily adjusted by renaming the entity in the UI. Below is a simple class, with the navigation property naming scheme.
These are some basic features of what's new. I cover these because these are practical for every developer who was used to Linq to Sql and liked some of these convenient conventions. Later on I will cover more practical elements to the framwork and to Visual Studio 2010.