This presentation, with Elisa Flasko, was covering an introduction to the entity framework and how it fits with common application patterns - client server, web applications and distributed N-Tier apps etc.
The ADO.NET Entity framework is the next layer up in the ADO.NET technology stack that allows us to describe data using a conceptual model mapped to the database using a declarative mapping and queries using LINQ to entities.
The demonstration started with replacing the data access layer of a client server application by importing an existing database structure. This pulled in the table structures and stored procedures of an existing database to an entity model, automatically resolving 1:n, 1:1 and n:n relationships to properties and collections etc.
The result of this was a graphical view of the entity model. This is where my first concern is with the entity framework. Visual tools simply do not scale in large scale applications - imagine having hundreds or thousands of entities - a graphical tool simply doesn't cut it. Once the number of entities increases to any significant number the visual model becomes cumbersome.
That aside, the demonstration then moved to consuming data. Rather than programming against the physical data model, you write code against the conceptual entity model. If you're at all familiar with OR/M solutions such as NHibernate or SubSonic, none of these concepts will be alien to you.
One nice facility was the seamless integration between EF and LINQ, allowing elegant, strongly typed and intellisense enabled queries to be defined. (This isn't unique to EF however, there is LINQ for NHibernate for example)
As you would hope, when queries execute, EF has a built in identity mapper pattern to ensure that only one instance of the same entity exists within the same context at any one time - this is an incredibly important feature to ensure you're always working with the correct and same unique object.
The presentation moved on to using EF in a web application and using object data sources within ASP.NET, with two way binding etc. As far as EF goes, the usage wasn't particularly different from using it in the client server environment.
Moving to N-Tier applications, as you might expect, the service layers utilise EF but then expose out from this data transfer objects (DTOs), although the speaker did mention that passing entities directly across the wire is possible. Personally I would always go for the DTO pattern as this represents best practice to send out only the data your clients need to consume.
Next, we looked at using ADO.NET data services (project Astoria) to expose an entity model directly over HTTP. This was reasonably cool, allowing the client to still query against the entity model using LINQ, but have this then executed remotely via your data service. Whilst this is a cool feature, it moves the responsibility for query to the wrong tier - the client should ask the service for data, the service should get it and return it appropriately - having the client issue any query it likes via the service breaks this separation, but is a cool feature non-the-less.
Whilst the EF is a very positive step forward in the OR/M space for Microsoft, the fact is that there are more mature, open and proven technologies already in existence (such as NHibernate), and that several other persons in the field have issued a vote of no-confidence for the framework which must all be considered before proceeding with an EF implementation.