Note: Some of the posts referenced in this post (!) are likely to be more out of date than others but I still feel that they are very much worth reading.

Whilst waiting for new Entity Framework bits to experiment with :-) I thought I'd start to write something about the Entity Framework and expand it over the coming weeks or months. This is mainly a "link" post to pull a few things together.

The Entity Framework is a new technology from the ADO.NET team.

The last time we had goodies from ADO.NET, it was in ADO.NET V2.0 where we (just like in V1.0) had the abstracted DataSet, DataTable and the provider-specific Connection, Reader, Adapter, Command classes that interact with a specific store.

You get a level of abstraction from ADO.NET 2.0 because you can program through generic interfaces rather than get involved with the particulars of (say) a SqlCommand or an OracleCommand but, ultimately, you still end up writing code that is store specific because you have to use T-SQL or PL/SQL with those commands in the end and differences in the underlying stores (such as what happens with stored procedures) ultimately bubble up through the abstraction.

There are also some factory bits in ADO.NET V2.0 to make it easier to create one or another provider's Commands (etc) by hiding the creation behind a factory wall.

So that's where we've been for quite a few years now but when ADO.NET 3.0 comes along it brings with it a whole new level of abstraction with the Entity Framework which has the potential to have a huge impact on the way in which we access data.

The big new idea of the Entity Framework is to stop querying the data store directly altogether and to start querying a conceptual model (an ER model) instead with a mapping technology that can translate your queries to the specifics of a store.

The Entity Framework calls this conceptual model the "Entity Data Model" or EDM.

This has a bunch of advantages such as;

1. The logical model of the relational store often isn't what an application developer wants to program against and writing explicit code to map it isn't productive.
2. The logical model of the relational store often isn't what a report writer wants to write a report against (and we've already seen a similar mapping approach in today's Reporting Services).
3. It's not always desirable to tie the application to the specific SQL dialect of one store (but it's very difficult to avoid it with ADO.NET 2.0).
4. It would be nice to make modifications to the store without altering the app but, instead, just altering the mapping.
5. It would be nice to potentially move to a different store without modifying the app but, instead, just altering the mapping.

You can get a lot more background information on the Entity Framework by;

1. Watching the screencasts linked to from here.
2. Checking out the whitepaper here.

And you can learn more about the Entity Data Model by;

1. Reading the whitepaper here
2. Reading this post and then following it with this post
3. Possibly adding in some of this post

In order to make all this work the Entity Framework has to be capable of offering query capabilities against the EDM whilst translating those to the logical model of the store.

It does this by providing a new ADO.NET provider, the EntityClient provider which slots into the existing ADO.NET extensibility model by providing a Command, Reader, Adapter, Connection.

In order to learn a little more about EntityClient check out;

1. This post on EntityClient
2. And this post which explains what this means for provider writers to plug-in to Entity Framework (i.e. it's not free :-))

Queries written against the EntityClient are written in Entity SQL (eSQL) which looks like SQL languages that we already know and love but also has some pretty snazzy capabilities.

To learn more about Entity SQL;

1. Check out this post (warning - this post requires caffeine as it's really good but quite long and fairly complex in places).

In order to translate those queries for the specific store, the EntityClient provider has to perform a translation which it does by consulting 3 metadata models (typically, but not necessarily (AFAIK), provided as XML documents);

1. Your EDM - this is described in "Conceptual Schema Definition Language" (CSDL).
2. Your store - this is described in "Store Schema Definition Language" (SSDL).
3. The translation between the two - this is described in "Mapping Schema Language" (MSL).

Of these, the SSDL is perhaps the most likely one that you can just have generated for you by pointing a tool (and there is one - edmgen.exe) at an existing store and saying "get me the SSDL from that store".

As it happens, you can also get CSDL and MSL generated but that's only really going to work for the scenario where you have a 1:1 mapping between your EDM and your store.

To learn more about Mapping;

1. Start here.
2. Carry on here.
3. Try a bit of this too.

So, with those necessary bits and pieces in place you can now do the "ADO.NET thing" and query this EDM model through the EntityClient provider in order to execute eSQL against that conceptual data model. So, you can write code like;

EntityCommand cmd = conn.CreateCommand();
cmd.CommandText = "SELECT p.ProductName, p.UnitPrice FROM NorthwindEntities.Product AS p";

And if you go ahead and execute that command and get yourself a reader and that reader will come back with 2 "columns" in it and it's the same old procedure that we're used to to enumerate and get those values out (i.e. while (reader.Read()) { reader["ProductName"], reader["UnitPrice"] }

To learn more about querying;

1. Read this post.

Something important to point out here - as far as I'm aware, you can only query the EDM model via eSQL. You can't update it that way - from looking at the current eSQL command reference there is no INSERT, UPDATE, DELETE right now and so you have to rely on other services of the EntityClient provider to do the CUD parts of your CRUD operations.

At that point you might be thinking - "Huh? What other services?" because the provider is already doing quite a bit of work to offer up this new SQL-like language and translate it into the underlying logical schema but it does a lot more than that. It also offers something that goes by the name of  "Object Services" which essentially takes the EntityClient and its EDM and offers Object Relational Mapping on top of that.

As far as I know, the mapping between the .NET Type layer and the EDM layer is 1:1 right now but I think that's just a default rather than a limitation. So, you can get direct access to the EDM by pulling collections of .NET types (e.g. the Customer type for the Customer entity defined in the EDM) out of the store and programming against them. The "Object Services" layer includes things that we've seen before in ORM layers including things like identity management, change tracking, transaction integration/management, automatic generation of insert/update/delete operations, concurrency management, integration of stored procedures and/or functions, easy navigation of relationships and so on

To follow up (a little - it's not a very long post) on Object Services check out;

1. This post

and there's some specifics around;

1. Inheritance.
2. Stored Procedures.

Also, there's quite a lot in that post I referenced on eSQL about how results are projected that plays into these object capabilities as well.

Now, it really wouldn't be very good if all of these capabilities didn't tie in to the "new kid on the block" - i.e. LINQ coming with Visual Studio 2008 so, depending on your needs, you can choose to write eSQL yourself or you can go ahead and use LINQ to Entities and define the queries using your language syntax (against the .NET types generated from your EDM) and get all the benefits of compile time checking, IntelliSense and so on that LINQ gives you.

That's pretty much all the references I wanted to share except that there's also an MSDN Magazine article to take a look at as well - provides a very good overview.

If you've managed to read all of this stuff then (like me) you're probably chomping at the bit for new Entity Framework bits to go with Visual Studio 2008. Maybe it's time to check back and see if they came out yet! :-)