Metadata, Objects and Values

One of the things I am doing at the moment is writing a bunch of Entity Framework code with one common theme, leveraging metadata.

In the spirit of transparency here is what I have learnt (just this, nothing else at all...)

When working with the entity framework from the developer perspective there are 3 layers:

· LINQ to Entities (L2E from now on).

· ObjectQuery<T>

· eSQL, EntityDataReader et al.

You can however think of these as APIs that surface Objects (L2E and ObjectQuery<T>) and Values (EntityDataReader). What do I mean by that? Well when I say Values I mean just the database values that we would need if we wanted to materialize Objects.

So the entity framework can surface Objects OR simply the objects' Values. This is important. Trust me, it is!

And here is why…

If you are working with Objects it almost goes without saying you will need to load the assembly in which they are defined. The fact that you need the assembly loaded means you can think of this as a form of binding, probably at compile time via a reference but possibly at runtime if you use reflection. Now it doesn’t really matter if you use L2E or ObjectQuery<T> directly, somewhere in your call stack you are using an ObjectQuery<T> bound to an ObjectContext.

On the other hand, if however you are working with Values all you need an EntityConnection, EntityCommand and finally an EntityDataReader. Which means you only need the System.Data.Entity assembly.

This enables scenarios where you can walk up to any set of CSDL/MSL/SSDL files and start querying straight away. Which is goodness.

I can almost hear the alert amongst you saying, “Sure Alex you can start querying, but for what?”

Well that is where metadata comes in…

Comments

• Anonymous
  November 13, 2007
  In my last post I hinted that using the Entity Frameworks Value layer and Metadata allows you to work
• Anonymous
  November 13, 2007
  In my last post I hinted that using the Entity Frameworks Value layer and Metadata allows you to work