In the recent blog post, How We Talk about EF and its Future Versions, the EF team announced that going forward, the stuff of EF that’s in .NET, will be referred to as the EF Core Libraries. For example, .NET 4 contains EF 4…that’s now core libraries. When .NET 4.5 is released, whatever is contained within System.Data.Entity.dll will be EF 4.5 Core Libraries.

As you may know by now, Code First and DbContext were released out of band of the .NET release schedule and is contained in the EntityFramework.dll assembly which is distributed via Nuget. Code First and DbContext rely on the core libraries to do their job. In the blog post, the team says “we are going to focus on the EntityFramework NuGet package as the primary deliverable that we refer to as “The Entity Framework” or “EF”.

This allows the team to be more flexible in releasing new features that leverage all of the work that’s gone into Entity Framework – features such as Code First and the DbContext API.

(For anyone writing or blogging etc about EF, please keep these differences in mind and be attentive to how you express EF.)

However, there’s something more important that I took away from the team’s blog post based on the fact that what’s in the NuGet package (DbContext and Code First) is what the team now refers to as “Entity Framework”.

What this means to me is that DbContext and Code First are the first features you should consider when approaching Entity Framework.

This makes a lot of sense to me. DbContext is much simpler to use than ObjectContext and will serve the most common development needs. if you need more, you can drop down into the ObjectContext. Remember that DbContext sits on top of the ObjectContext. The ObjectContext is always there in the background doing it’s work. So if you need to do something very granular, DbContext provides a hook to its underlying ObjectContext. Check out this blog post for how to do that: Accessing ObjectContext Features from EF 4.1 DbContext. Or, if you are already committed to working directly with the ObjectContext, you can still do that.

What about database first and model first? The designer is still inside of Visual Studio (and getting improvements) and there are 3rd party designers as well. If Code First doesn’t do the trick for you, you really want a visual model — or you’re already committed to EDMX — no worries. The feature  is still there and you will not be a pariah for using the designer. Use the best tool for the job … for *your* job!  (Here’s an article I wrote about choosing between db/model & code first)

The core EF Libraries know how to use the XML based metadata that come from the EDMX. At runtime, EF uses an in-memory representation of your model. If your model is expressed in XML (from the designer), the ObjectContext knows how to read the XML to create what it needs at runtime. (Even if you’re using DbContext + EDMX, this works…because DbContext has an ObjectContext behind it). If your model is expressed in classes plus Code First configurations, the context knows how to use those pieces to build the in-memory metadata at runtime. After that, EF doesn’t care where the model came from.

So the primary focus of Entity Framework going forward will be building models with your classes plus Code First and managing your entities with the DbContext. When the team talks about Entity Framework, (according to their blog post) that’s most likely what they’ll be referring to.

There’s ANOTHER take away here. Code First leverages the POCO support that was built into the core in .NET 4. (see what I just did there? ) EntityObject is now the ugly step-child of Entity Framework. After working mostly with POCOs in EF for over a year now, I feel the same way about EntityObject. No love lost there!

When the team makes changes to how the core EF libraries (those which are part of .NET), again …popular examples are upcoming enum support and spatial data support … they’ll be clear that this is part of the core. Changes to the core benefit all of the ways to use EF …whether you build your model with a designer or with code and whether you use the ObjectContext or DbContext.

I’ve just finished up a book with Rowan Miller that is something of an extension to my book, Programming Entity Framework Second Edition (which is focused on Entity Framework 4). The new book is about 150 pages and is called “Programming Entity Framework Code First: Creating and Configuring Data Models from your Classes”. Very specifically about the modeling/mapping and DB initialization. We are now embarking on another short book that will be Programming Entity Framework DbContext. This second one will be focused on the DbContext APIs, validation and how to use them in various application patterns.

I’m excited about embarking on  my first full-week workshop. Until now, I have done a number of one-day workshops but I have always felt that I needed more time. There’s so much to share! Maybe five days will be enough?

The workshop will be in Boston (Waltham, to be exact) the first week of October. It is being coordinated by www.dataeducation.com.

Below is the course outline.

There is currently a $400 early bird discount until the end of August.

Details and registration at http://dataeducation.com/entity-framework-bootcamp/

Day 1: Introducing Code First

• Why Code First?
• How does Code First work at runtime?
• Configuring Code First with Data Annotations and with the Fluent API
• Configuring for validation, data attributes, relationships, database mappings and hierarchies
  • Understand impact on database
  • Understand impact on your application at runtime
• Code First database initialization
  • Understand default and optional behavior and workarounds

Day 2: Introducing EF 4.1 DbContext /DbSet

• How do DbContext and DbSet compare to ObjectContext/Object Set
• Explore features of DbContext/DbSet that streamline EF coding
• Integrate DbContext with your apps
• Validation API
• Fun with MVC 3 and EF 4.1

Days 3-5: Hard Core EF 4 (and 4.1)

• Architecting maintainable and testable enterprise apps with EF4/4.1
  • Repositories, unit of work, testing
• EF in distributed architectures: ASP.NET, WCF Services, WCF Data Services
• EF in the Cloud: Windows Azure and SQL Azure
• EF performance tips and tricks
• Working with large models and multiple contexts
• Explore EF core API additions and improvements introduced in the June 2011 CTP
  • Enum support, spatial, TPT improvements, designer improvements and more

Well, this change really came in the March 2011 CTP but I didn’t realize it until the June CTP was out, so I’ll call it a wash.

WCF Data Services has had a bad problem with inherited types where the derived type had a relationship to yet another type. For example, in this model where TPTTableA is a derived type (from Base)and has related data (BaseChildren).

If you expose just the Bases EntitySet (along with its derived type) in a WCF Data service, that was fine. I can browse to http://localhost:3958/WcfDataService1.svc/Bases easily.

But if I also exposed the related type (BaseChild) then the data service would have a hissy fit when you tried to access the hierarchy base (same URI as before). If you dig into the error it tells you:

“Navigation Properties are not supported on derived entity types. Entity Set ‘Bases’ has a instance of type ‘cf_model.ContextModel.TPTTableA’, which is an derived entity type and has navigation properties. Please remove all the navigation properties from type ‘cf_model.ContextModel.TPTTableA’”

Paul Mehner blogged about this and I wrote up a request on Microsoft Connect. Here’s Paul’s post: Windows Communication Foundation Data Services (Astoria) – The Stuff They Should Have Told You Before You Started

But it’s now fixed!

Using the same model, I can expose all of the entity sets in the data service and I’m still able to access the types in the inheritance hierarchy.

Here is an example where I am looking at a single Base entity and in fact this happens to be one of the derived types, notice in the category the term is cf_model.TPTA. The type is strongly typed.

You can see that strong typing in the link to the related data:

Bases(1)/cf_model.TPTA/BaseChildren

That’s how the data service is able to see the relationship, only off of the specific type that owns the relationship.

So accessing the relationship is a little different than normal. I struggled with this but was grateful for some help from data wizard, Pablo Castro.

The Uri to access the navigation requires that type specification:

http://localhost:1888/WcfDataService1.svc/Bases(1)/cf_model.TPTA/BaseChildren

You also need that type if you want to eager load the type along with it’s related data:

http://localhost:1888/WcfDataService1.svc/Bases(1)/cf_model.TPTA?$expand=BaseChildren

Note that I was still having a little trouble with the navigation (the first of these two Uris). It turns out that cassini (i.e. the asp.net Web Development Server) was having a problem with the period (.) in between cf_model and TPTA.

Once I switched the service to use IIS Express (which was my first time using IIS Express and shockingly easy!), it was fine. (Thanks again to Pablo for setting me straight on this problem.)

So it’s come a long way and if this is how it is finalized, I can live with it though I guess it would be nice to have the URIs cleaned up.

Of course you’re more likely to use one of the client libraries that hide much of the Uri writing from us, so maybe in the end it will not be so bad. I have not yet played with the new client library that came with this CTP so I can’t say quite yet.