It has been longer in arriving than I would have liked, but the June CTP of the Entity Framework is finally out. This includes a HUGE set of changes. I can’t tell you how many times lately I’ve responded to a question on the forum or something like that with “that’s fixed in the next CTP.” Finally, it’s here. Here’s a partial list of the features (largely plagarized from the ADO.Net team blog post on the topic)
- IPOCO — there’s a lot more coming here to bring us closer to true POCO, but this is the first step in that direction and makes the key change to allow the creation of Entity classes that do not inherit from our base class.
- ObjectContext.Detach() — will detach an object from the ObjectStateManager associated with an object context so that it can be attached to some other context or reclaimed by the garbage collector
- Multiple entity sets per type — this is relatively esoteric, but it does exactly what its name says. You can define a model which has more than one entity set with the same base type. This is important because it enables models which work more naturally with various database models. If you have two tables with the same schema (say “accounts” and “expired_accounts” or something), then you can define entitysets for each of them which use the same entity type rather than needing to create a different entity type which just happens to have all the same properties. This resulted in a change to a number of the object context APIs — strongly typed contexts, for instance, now have AddToEntitySetName methods (where EntitySetName is the actual name of each entity set).
- Support for referential integrity constraints — This allows you to define a key to one entity type which is made up, in part, of properties which are also in the key of another entity type. The modeling scenario in the database is where a column is both a foreign key and part of a primary key.
- Span — this makes it possible to specify that a query not only return an entity but return some set of related entities in a single round trip and automatically hook-up the graph. So, for instance, you could say that your customer query should also return the orders for each customer in a single round trip. We also have an automatic query re-write feature for the object layer that enables a feature we call Relationship Span where queries that retrieve entities will under-the-covers also return relationship information if the relationship is an EntityReference (rather than a collection). This is usually a quick operation since typically this relationship information is co-located in the relational database as a foreign key property, and it has the very useful property that for many cases entity graphs will automatically be hooked up as long as the relevant entities on either side of the relationship have been loaded. So, for example, if I query for a set of customers and then I separately do a query for a bunch of orders–any of those orders that are related to those customers will automatically bring along the relationship info and connect the orders up to the customers they go with.
- Transactions — specifically integration with System.Transactions.
- Serialization — that is, entities are automatically generated with attributes that enable binary serialization. Unfortunately EntityKeys do not yet serialize but that will be coming in a future CTP.
- No more default constructors in code-generated classes — I’ve already written about this in an earlier blog post.
- Improvements to stored procedure support — honestly I can’t remember the details of this one just now, and since I’m sitting in the Denver airport where I have limited battery life on my laptop I’ll delay looking it up for you. If anyone is wondering, drop me a note and I’ll get back to you.
- Access to the underlying store connection — You can now easily access the store connection from an EntityConnection which makes it much easier to go around the covers if you need to. (But I must say I don’t have to do that nearly so often now as I used to — this framework is actually starting to work pretty well for writing apps, IMHO <grin>.)
- Directory macros — Makes it easier to specify where the metadata lives in hosted scenarios
- Native SQL read-only views — You’ve got to see one of the demos Tim Mallalieu runs where he shows the entity framework accessing sharepoint or some other schema that otherwise really doesn’t fit the model.
- UNICODE support in Entity SQL
- Query plan caching and I’m pretty sure we do some metadata caching across app domains as well, but that may not be fully online yet in this CTP release.
- Canonical functions in Entity SQL
- Associations between sub-types — This one is a biggy (as if the others aren’t). Before this change, the entity types that are on the ends of relationships had to be the base type of an entityset, but after this change you can define relationships between any types in the type hierarchy even if they aren’t the base types. So, for instance, if I have a hierarchy that has Customer and BigAccountCustomer, then I could create an entity type DiscountPolicy and a relationship that only relates BigAccountCustomers to DiscountPolicies not just regular customers.
I’m sure there’s more in there, but that should give you a taste of things. That’s all the good news. The bad news is that all these changes brought along with them a number of API and metadata schema changes, so if you have apps you’ve been working on with beta 1, a number of changes will be needed to get your apps working again with this CTP. If your experience is anything like mine, though, the real major changes in your app will come from taking advantage of all the new features to completely remodel things with associations between subtypes and RI constraints, to use span, etc.
As always, comments and feedback are more than welcome. We’re really looking forward to hearing what you think.
P.S. One other small bit of bad news: Complex Types didn’t make it into this CTP. So if you are holding out for them, unfortunately you’ll have to wait for the next round.