Entity Framework Design : ObjectServices

Code Only

efdesign — Wed, 10 Jun 2009 23:04:00 GMT

There are currently two ways to get Entity Framework apps up and running, we call these Database First and Model First respectively.

Database First has been with us since .NET 3.5 SP1, and involves reverse engineering an Entity Data Model from an existing database.

Model First is new to Visual Studio 2010/.NET 4.0 and allows you to create an Entity Data Model from scratch and then generate a database and mapping for it.

However many developers view their Code as their model.

Ideally these developers just want to write some Domain classes and without ever touching a designer or a piece of XML be able to use those classes with the Entity Framework.
Basically they want to write ‘Code Only’.

We are pleased to announce that we’ll be shipping a preview of “Code Only” on top of the .NET Framework 4.0 Beta 1 (more on that in the coming days).

How it works:

To use Code only you simply write some POCO classes, here is a simple example:

public class Category
{
   public int ID { get; set; }
   public string Name { get; set; }
   public List<Product> Products { get; set; }
}

public class Product
{
   public int ID { get; set; }
   public string Name { get; set; }
   public Category Category { get; set; }
}

Then write a class that derives from ObjectContext that describes the shape of your model and how you want to access your POCO classes, so something like this:

public class MyContext : ObjectContext
{
   public MyContext(EntityConnection conn)
    : base(conn){ }
   public ObjectSet<Category> Categories {
      get {
         return base.CreateObjectSet<Category>();
      }
   }
   public ObjectSet<Product> Products {
      get {
         return base.CreateObjectSet<Product>();
      }
   }
}

NOTE: this persistence / EF aware class could easily be in another assembly so you can keep it separate from your nice pristine domain classes.

At this point you have everything you need from a CLR perspective, but you won’t be able to use the MyContext class without some EF metadata, which is normally stored in the EDMX file.

But remember Code-Only means there isn’t an EDMX file.
So where do we get the metadata?
That is where the ContextBuilder class comes in:

SqlConnection connection = …; // some un-opened SqlConnection
MyContext context = ContextBuilder.Create<MyContext>(connection);

What is happening here is that the ContextBuilder is looking at the Properties on MyContext, inferring a default Conceptual Model, Storage Model and Mapping by convention, it the uses that metadata plus the SqlConnection you passed in to create an EntityConnection, and finally it constructs an instance of MyContext by passing the EntityConnection to the constructor we created previously.

Once you have an instance of your context, we ship several extension methods you can use to automatically create a database script, see if the database exists, drops the database, and/or create the database,. For example this code snippet uses two of those extension methods to create the database if it doesn’t already exist.

if (!context.DatabaseExists())
context.CreateDatabase();

The CreateDatabase call looks at the EF metadata, in particular the Storage Model, aka SSDL, and uses it to produce Database Definition Language (or DDL) which it then executes against against the connection.

Overriding Conventions

In the examples so far everything is done by convention. This is great if you are happy with our conventions. However you may want to override them, for example to register different keys, use different mappings or use a different inheritance strategy etc.

To override the convention instead of creating an ObjectContext directly you create an instance of a ContextBuilder that you can configure.

var contextBuilder = new ContextBuilder<MyContext>();

In the first Feature CTP, Code Only provides the ability to override how the key properties are inferred:

contextBuilder.RegisterKey((Product p) => p.ID);

This code tells the builder that the key of Product is its ID property.

When you’ve finished configuring how you want your model and mappings to work in your code, you create an instance of your context, this time by calling Create on the builder instance you have been configuring:

MyContext context = contextBuilder.Create(connection);

It is that simple.

Over time the features of the ContextBuilder will grow so you will be able to setup custom mappings, mark properties as transient, setup up Facets (e.g. MaxLength), change inheritance strategies, link properties that are the inverse of each other together (e.g. product.Category and category.Products) and more. In fact here is an example of the sort of thing we are aiming to support for the next release of the Feature CTP:

builder[“dbo.prds”] =
from c in builder.OfType<Product>()
select new {
    pcode = p.ID,
    p.Name,
    cat = p.Category.ID
}
);

This snippet:

Maps Product entities to the ‘prds’ table.
Maps Product.ID to a ‘pcode’ column.
Maps Product.Name to a ‘Name’ column.
Maps the FK under the Product.Category relationship to the ‘cat’ column.

Here is another example that does basic TPH inheritance:

builder[“dbo.Cars”] = (
from b in builder.OfTypeOnly<Car>()
select new {
     id = b.CID.AsKey(),
     b.Color,
     b.Manufacturer,
     disc = “C”
   }
).Merge(
from s in builder.OfType<SportsCar>()
select new {
     id = s.CID.AsKey(),
     s.Color,
     s.Manufacturer,
     disc = “S”,
     hp = s.HorsePower,
     tq = s.Torque
}
);

These two examples just scratch the surface of what we are planning on doing, hopefully though they give you a sense of where we are heading.

We are super excited about Code Only. But as of right now our plans to support overriding conventions aren’t finalized, so we’d love to get your feedback, this really is your chance to help us get it right.

Alex James,
Program Manager, Entity Framework Team, Microsoft

This post is part of the transparent design exercise in the Entity Framework Team. To understand how it works and how your feedback will be used please look at this post.

N-Tier Improvements for Entity Framework

efdesign — Thu, 20 Nov 2008 08:33:00 GMT

The first version of Entity Framework provides convenient ways to load, manipulate and persist objects and relationships. As with many other O/RMs, Entity Framework has a state manager that tracks every change made. Existing objects are typically loaded first from the database, later modified, and finally the changes are saved back to the store.

Another feature, full graph serialization, makes it very easy for developers to ship around object graphs representing snapshots of the current state of the world, across execution boundaries.

The next version of Entity Framework will also support Persistence Ignorance. Therefore object graphs can now be made of POCO instances, which WCF now also supports.

Nonetheless, there is a task that belongs in any N-Tier application that still requires a great amount of work for developers using EF: decoding messages that represent state changes performed by the client, meant to be processed or persisted by the service.

The major pain point in the first version is the number of intricate steps a program needs to perform in order to setup the state manager in the appropriate state according to the changes encoded in the message. For instance, for any but the simplest scenarios, in order to use the basic graph manipulations APIs in ObjectContext, like AddObject and AttachTo, it is necessary to “shred” the object graphs contained in the message, which destroys important information about relationships between object instances that therefore has to be kept somewhere else (as an illustration of this approach, see Danny Simmons’s EntityBag in project Perseus).

In addition, given that the message typically contains all the necessary information and that concurrency is usually a concern, the program shouldn’t have to re-query the database. Instead, it should be easier to “tell” the state manager about the original state (that came from the database previously) and about what changes were made.

There are a few approaches to N-Tier that are very popular in the industry. Customers using Entity Framework for the first time often carry the expectation that it will support a similar experience:

DataSet

The original ADO.NET data access technology includes the DataSet, a versatile data cache that can be serialized as XML and be used to transport collections of rows and relationships and, also diffgrams representing changes.

DataSets make many N-Tier scenarios extremely easy to implement, and over time, have proven helpful for many customers. In spite of this, they are not appropriate for some scenarios and architectural patterns:

The lack of a widely accepted standard serialization format has hindered the development of implementations that could produce or consume datasets in other platforms.
Diffgrams represent sets of CREATE, UPDATE and DELETE operations of arbitrary depth, which is not adequate for architectural patterns that conceive operations with more constrained semantics (i.e. PlaceOrder, CreateCustomer).
No simple ways to control the application of batch CUD operations contained in diffgrams makes them unsuitable any time there is a trust boundary between the client and the server.
Also, the data-centered perspective of DataSets leads to an anti-pattern known as the “anemic domain model”, which is characterized by a separation between the data aspect and the behavioral aspect of domain objects.

Data Transfer Objects

The approach typically used in the DDD and SOA communities to address multi-tier scenarios is to hand-build a service with well defined operation semantics together with the a conceptual message format, usually composed of data transfer objects (DTOs). Implementing DTOs often also involves writing the logic that translates DTOs back and forth to persistent objects.

Here is a simplified set of rules that characterizes the use of DTOs:

Actual entities are not serialized, just DTOs, which are value-only objects (without behavior) are exposed in the boundaries.
The client does not depend on the types defined on the server. The shapes of the DTOs are the sole contract, and the types used in the client are for the client only.
The context or container is not sent together with the message.
The service decides what to do with the contents of the message. It is not the message who decides (as an extreme counter example, imagine a message that tells the service to delete all the contents of the database).

Those rules are especially important in SOA scenarios, in which the client and the server can be separated by a trust boundary, such as the one that exists between two different companies.

There are other permutations of layered architectures, though, in which the level of decoupling that DTOs provide may not justify the increased complexity, for example:

A multi-tier application in which the client is fully trusted.
A rich internet application in which an infrastructure service is purely used for data persistence (is by design a CRUD-only service) and therefore types exposed do not contain behavior anyway.
Any architecture in which the persistence framework is actually used to provide and manage DTOs and not the actual entities.

REST

ADO.NET Data Services provides a rich framework that developers can easily use to expose any Entity Data Model as a REST-style resource collection. Simple HTTP verbs like GET, PUT, POST and DELETE are used in combination with URIs to represent CRUD operations against the persistence service.

This pattern is suitable for many applications and can easily be combined with service operations with richer semantics in the same application.

ADO.NET Data Services, however, may not be compelling for those customers who want to define their services as operations with richer semantics entirely.

Goals

ADO.NET Data Services goes a long way addressing the needs of customers doing RESTful services, and so there is no need for us to improve Entity Framework experience on that space.

With the N-Tier improvements for Entity Framework, we want to address some of the same problem space as DataSet, but we want to avoid the primary issues with it.

Ideally, we would like to provide building blocks that are appealing for developers building solutions on a wide range of architectures. For instance, we would like to provide fine enough control for DTO proponents, but at the same time reduce the level of pain that those trying to address simpler scenarios experience today.

Design

If we just wanted to provide a DataSet like experience on top of Entity Framework, the most straightforward (although very expensive to test) way would probably be based on full serialization of the state manager. Basically, the internal representation of ObjectStateManager includes collections of objects to be deleted, inserted, and modified, and also relationships to be added and deleted, as well as objects and relationships that should remain unchanged.

Such a model would lead to very fine grain control of the state manager, but you would lose some of the benefits of operating on the domain objects and the higher level APIs. For instance, it would make it extremely easy for the program to set the state manager in a completely invalid state.

An alternative representation for such an experience would be to ship a “change log” containing the history of all operations performed on the client. This representation has the disadvantage of being more verbose than the previous one, but it would make “point in time” rollbacks pretty easy to implement.

Besides these two, there are a few more interesting generic representations for changes in a graph, but in general, they all suffer from the same disadvantage: providing a solution for them does not give the user the level of control that the most complicated scenarios and sophisticated patterns require.

Based on this fact, we decided to adopt the following goal for the design:

Entity Framework won’t define its own unique representation for the set of changes represented in an N-Tier application. Instead, it will provide basic building block APIs that will facilitate the use of a wide range of representations.

This has the desirable consequence that Entity Framework won’t impose a pattern for N-Tier. Both DTO-style and DataSet-like experiences can be built on top of a minimal set of building blocks APIs. It is up to the developer to select the pattern that better suits the application.

Here is a first cut of the new methods that we are proposing to add to the ObjectContext. The new APIs will work with EntityObjects, IPOCO and POCO entities:

public partial class ObjectContext 
{ 
    /// <summary> 
    /// Apply property values to original state of the entity 
    /// </summary> 
    /// <param name="entitySetName">name of EntitySet of root</param> 
    /// <param name="original">entity with original values</param> 
    public void ApplyOriginalValues( 
        string entitySetName, 
        object original) { } 
    
    /// <summary> 
    /// Changes the state of the entity and incident relationships 
    /// </summary> 
    /// <param name="entity">entity to change state of</param> 
    /// <param name="state">new state</param> 
    public void ChangeObjectState( 
        object entity, 
        EntityState state) { } 

    /// <summary> 
    /// Changes state of relationship 
    /// </summary> 
    /// <param name="source">source object of relationship</param> 
    /// <param name="target">target object of relationship</param> 
    /// <param name="relationshipName">name of relationship</param> 
    /// <param name="sourceRole">role of source object</param> 
    /// <param name="targetRole">role of target object </param> 
    /// <param name="state">new state</param> 
    public void ChangeRelationshipState( 
        object source, 
        object target, 
        string relationshipName, 
        string sourceRole, 
        string targetRole, 
        EntityState state) { } 

    /// <summary> 
    /// Changes state of relationship represented by navigation 
    /// property 
    /// </summary> 
    /// <param name="source">source object of relationship</param> 
    /// <param name="target">target object of relationship</param> 
    /// <param name="navigationProperty">navigation property</param> 
    /// <param name="state">new state</param> 
    public void ChangeRelationshipState( 
        object source, 
        object target, 
        string navigationProperty, 
        EntityState state) { } 
    
    /// <summary> 
    /// Changes state of relationships represented by lambda 
    /// expression 
    /// </summary> 
    /// <typeparam name="TSource">type of source entity</typeparam> 
    /// <param name="source">source entity of relationship</param> 
    /// <param name="target">target entity of relationship</param> 
    /// <param name="selector">property selector expression</param> 
    /// <param name="state">new state</param> 
    public void ChangeRelationshipState<TSource>( 
        TSource source, 
        object target, 
        Expression<Func<TSource, object>> selector, 
        EntityState state) { } 
  
} 

ApplyOriginalValues

Similar to the existing ApplyPropertyChanges, but this API keeps the tracked entity intact, only affecting the corresponding original values. This operation only works for entities in Modified, Unchanged or Deleted states. Added entities by definition don’t have original state.

ChangeObjectState

This method will transition the state of a tracked entity passed as argument, but will also have side-effects on incident relationships. In case the new state is modified, it will also mark all properties as modified, regardless of the original and current values.

ChangeRelationshipState

Similar to ChangeObjectState, but sets the relationship between two tracked entities to the provided state. Relationships cannot be in the modified state, but this method can be used to report which relationship should be added, deleted, or unchanged.

The relationship doesn’t need to exist in the context, but the entities do. If the relationship doesn’t exist, it can be created in the new state. For instance, when this code is invoked, a new relationship can be created between customer1 and order1 in the added state:

context.ChangeRelationship( 
    customer1, 
    order1, 
    c=>c.Orders, 
    EntityState.Added); 

The relationship is typically represented by the navigation property but the metadata names of the relationship and roles can also be used in a different overload.

Design notes

All parameters named “entity”, “source” and “target” accept either entities or EntityKeys.
We could choose to deprecate the ApplyPropertyChanges API and replace it with ApplyCurrentValues, which is more consistent name-wise with the new ApplyOriginalValues method.
For convenience, we should add similar APIs in other types like ObjectStateEntry, RelatedEnd and others as appropriate. For instance, the ObjectStateEntry will also have a ChangeState API that will only take the target state parameter.
We could choose to put ChangeObjectState() and the various ChangeRelationshipState() in ObjectStateManager rather than in ObjectContext, since this is a lower level API than everything else currently in the ObjectContext.

Scenario tests

To get a sense of how the new API can be used, we have tried several different approaches and representations. We also have plans to release sample code that will show in more detail different ways to use the new API. In the meanwhile, here are a few simple cases.

General purpose Attach with state resolution delegate

In this scenario between a client and mid-tier, the intention is to allow a client to query for a Customer entity with the Customer’s Order entities. The client then makes a variety of changes to the Customer entity graph including modifying the Customer, and adding or removing Orders. The client would like to send the updated Customer entity graph to the mid-tier so that it can be processed and persisted.

This system will use a simple mechanism to help with change tracking on DTO entities. Each DTO will implement a small interface to help determine the state of the entity using three properties: IsNew, IsModified, and IsDeleted. In this example, original values are not tracked by the client.

public interface IEntityWithChanges 
{ 
    bool IsNew { get; } 
    bool IsModified { get; } 
    bool IsDeleted { get; } 
} 

When the client makes changes to the Customer entity graph, the only requirement in this scenario is that when an entity changes, the appropriate property will return true to help determine the state of the entity.

The mid-tier will expose a service method that implements the logic to update the Customer entity graph. Rather than traverse the Customer, her Orders and OrderLines looking for changes, the service method will use a convention based mechanism that knows how to deal with the IEntityWithChanges interfaces. In this scenario, this mechanism takes the form of an extension method to the ObjectContext that will attach an entity graph to the context, and use a delegate to map each entity that implements IEntityWithChanges to an EntityState so that it can be used with the new ChangeObjectState APIs.

First we can define a method to map from an IEntityWithChanges to an EntityState:

/// <summary> 
/// A mapping from an IEntityWithChanges to an EntityState 
/// </summary> 
public EntityState GetEntityState(object entity) 
{ 
    IEntityWithChanges entityWithChanges = 
       entity as IEntityWithChanges; 
    if (entityWithChanges != null) 
    { 
        if (entityWithChanges.IsNew) 
        { 
            return EntityState.Added; 
        } 
        else if (entityWithChanges.IsModified) 
        { 
            return EntityState.Modified; 
        } 
        else if (entityWithChanges.IsDeleted) 
        { 
            return EntityState.Deleted; 
        } 
    } 
    return EntityState.Unchanged; 
} 

Next we will define the extension method on an ObjectContext that can attach an entity graph and use a mapping delegate to determine the state of each entity in the graph.

/// <summary> 
/// Attach a graph of entities using a supplied mapping function to 
/// determine the entity's state. 
/// In this example, the state of relationships between entities is 
/// determined by the rules of ChangeObjectState: 
/// - if one entity in the relationship is Added, the relationship is 
///   Added 
/// - if an entity is Deleted or Detached, all incident relationships 
///   are Deleted or Detached 
/// </summary> 
/// <param name="entitySetName">name of EntitySet of root</param> 
/// <param name="entityGraph">graph of entities to attach</param> 
/// <param name="entityStateMap">EntityState resolver</param> 
public static void Attach( 
    this ObjectContext context, 
    string entitySetName, 
    object entityGraph, 
    Func<object, EntityState> entityStateMap) 
{ 
    context.AttachTo(entitySetName, entityGraph); 

    // Create a list of unique entities in the graph 
    var allEntities = 
        context 
        .ObjectStateManager 
        .GetObjectStateEntries(EntityState.Unchanged) 
        .Where(entry => !entry.IsRelationship) 
        .Select(entry => entry.Entity); 
        
    // Apply the entityStateMap to each entity 
    foreach (object entity in allEntities) 
    { 
        context.ChangeObjectState(entity, entityStateMap(entity)); 
    } 
} 

Finally we can define our service method that can update a Customer entity graph using the mapping delegate and the Attach extension method.

/// <summary> 
/// A service method to update a Customer's entity graph which 
/// can include modifications to the Customer entity, 
/// new Orders, and removal of Orders 
/// </summary> 
/// <param name="c"></param> 
public void UpdateCustomerOrder(Customer customer) 
{ 
    using (NorthwindEntities context = new NorthwindEntities()) 
    { 
        // Call the Attach extenion method with the mapping delegate 
        // that goes from IEntityWithChanges to EntityState 
        context.Attach("Customers", customer, GetEntityState); 
        context.SaveChanges(); 
    } 
} 

ChangeOrder Service Operation

In this scenario, the mid-tier exposes a method to perform a very specific operation: changing the Customer that owns an Order. The client can set the Order’s Customer to a new Customer or to one that already exists in the store. In either case, the service method uses the old Customer so that it can remove the relationship between the Order and that Customer.

/// <summary> 
/// Updates an Order by changing the relationship between the Order 
/// and a Customer in this case 
/// </summary> 
/// <param name="updatedOrder">order to update</param> 
/// <param name="oldCustomer">previous customer</param> 
public static void ChangeOrder( 
    Order updatedOrder, 
    Customer oldCustomer) 
{ 
    using (NorthwindEntities context = new NorthwindEntities()) 
    { 
        // Tell the context about the entities to persist 
        context.AttachTo("Orders", updatedOrder); 
   
        // Change the state of the new customer 
        // In this example, this is done by the convention: 
        // - Customer.CustomerID is null --> customer is 'Added' 
        // - Customer.CustomerID is not null --> it already exists 
        if(updatedOrder.Customer.CustomerID == "") 
        { 
            // When state of customer changes to 'Added', state 
            // of the relationship between updatedOrder and 
            // pdatedOrder.Customer is also changed to 'Added' 
            context.ChangeObjectState( 
                updatedOrder.Customer, 
                EntityState.Added); 
        } 
        else 
        { 
            if (updatedOrder.Customer.CustomerID != 
                oldCustomer.CustomerID) 
            { 
                // only relationship needs to be marked as 'Added' 
                context.ChangeRelationshipState( 
                    updatedOrder, 
                    updatedOrder.Customer, 
                    o => o.Customer, 
                    EntityState.Added); 

                // Report removal of relationship between 
                // pdatedOrder and oldCustomer 
                context.ChangeRelationshipState( 
                    updatedOrder, 
                    oldCustomer, 
                    "Customer", 
                    EntityState.Deleted); 
             } 
        } 
        
        // Persist the changes to the store 
        context.SaveChanges(); 
    } 
} 

As is always the case, your feedback on this topic is welcome!

Jeff Derstadt
Jaroslaw Kowalski
Diego Vega
and The Object Services Team

This post is part of the transparent design exercise in the Entity Framework Team. To understand how it works and how your feedback will be used please look at this post.

Foreign Keys in the Conceptual and Object Models

efdesign — Mon, 27 Oct 2008 19:48:00 GMT

If you are reading this, you have probably heard by now about the so called impedance mismatch between the relational world and the object world – and there are a number of concepts in the relational database that don’t translate easily to corresponding concepts supported by the object oriented paradigm. One of these factors that is particularly interesting (and often controversial) is the concept of Foreign Keys and whether or not they belong in your conceptual/object model.

FKs are used to represent relationships in the database – but with objects, the natural way to represent relationships is through real references between objects. So as an object relational mapping platform, should a product support one or the other, or both?

I think most will agree that there is tremendous value in supporting relationships in the model as first class references between objects.

What are some of the issues with supporting both foreign keys and references in the same model? We could take a real world example i.e. LINQ to SQL and its foreign key support to look at some of the benefits as well as the downsides to having foreign keys.

Foreign Key Support in LINQ to SQL

LINQ to SQL takes the simplistic approach of making foreign keys available to you as a scalar property in your entities. In essence, LINQ to SQL allows you to write code dealing with relationships like so:

Product chai = db.Products.Where(p => p.ProductName == "Chai").Single(); 
chai.CategoryID = 1; 
db.SubmitChanges(); 

This is possible in LINQ to SQL mainly because foreign keys are somewhat central to the way relationships are implemented and supported.

This particular example achieves something quite powerful, however - here you have essentially changed the category that the product Chai belonged to without ever having to query and materialize the new category that you associated Chai with.

However, LINQ to SQL also allows you to do this:

Product chai = db.Products.Where(p => p.ProductName == "Chai").Single(); 
Category beverages = db.Categories.Where(c => c.CategoryName == "Beverages").Single(); 
chai.Category = beverages; 

We have been considering for a while about whether or not we want to include support to allow you to expose foreign keys in the model. Let’s see what you gain / lose by having foreign keys in the model.

One of the fundamental issues is that the simple foreign key concept that works so well in the relational model isn’t sufficient to represent relationships in the conceptual model. In the Entity Framework, a relationship is a first class concept that must be mapped to any set of columns in the database – and the important thing here is that these columns don’t have to represent relationships on the database by the means of FKs and constraints. Another point to note is that in the Entity Framework, relationships are always comprised of two ends, and are bi-directional unlike foreign keys.

What does all of this do for the model? This opens up possibilities, such as Referential Integrity constraints that are represented in the EDM even though they may not necessarily be present on the relational model in the store. Bi-directional nature of the relationships makes it possible for you to navigate in both directions along a relationship in a way that is generally not possible with a simple FK.

Foreign Keys are not without value, however. An interesting challenge for us is to figure out how to bring the best aspects of Foreign Keys into the Entity Framework without compromising the richness and flexibility that relationships bring to the table. Let’s look at the upside and the downsides of plain relational foreign keys:

Benefits of Foreign Keys

Keeps it simple (for the simple cases) and allows you to deal with relationship like you deal with them in the database
Technically, you can update relationships without having both ends loaded/materialized. This is however in reality not always interesting since you will likely load both ends but this feature is definitely useful.

Disadvantages of Foreign Keys in the Model

It is a part of the impedance mismatch problem.
It doesn’t allow the concepts that you would expect from relationships in objects (easily getting from one end to the other) for instance.
Having foreign keys as well as object references for relationship navigation presents the problem of two different artifacts representing relationships – this introduces complexity and now you have to make sure that you keep these two in sync.

So where do you stand? Do you like foreign keys or do you think they are evil? Would you like to see Foreign Keys exposed in the model, and if they are available in your object model, would it be sufficient if they were read-only?

Let us know!

Faisal Mohamood
Program Manager,
Entity Framework Team

This post is part of the transparent design exercise in the Entity Framework Team. To understand how it works and how your feedback will be used please look at this post.