EF should decouple the implementation of the entity objects from the mapping functionalities. The EF team could provide the current entity creation as a default variant which can be attached to the mapper. The developer has the option to provide it's own data transfer object layer. Therefore we need to abstract the entities through interface usage an a generic naming schema (dot notation of an object model like Person.Name). So the EF would be much more flexible to use.

Note by Diego Vega: I am merging this idea with a few other ideas that are approximately equivalent but extend in other directions:

- On one hand we could support materializing objects invoking constructors with parameters and non-publically settable properties. Another way to do it (popular in among users of other O/RMs) would be to support materializing to private fields. In addition, we could support registering factory methods or some other resolution mechanism like plugging in an IoC container.

- On one hand, support for materialization of objects with constructors with parameters could be transparent, e.g. the query db.Customers doesn't need to specify how each customer needs to be constructed. It just specifies that customers can be queried using this property. On the other hand, we could also allow explicitly constructing an object with a constructor with parameters in the outmost projection: db.Customers.Select(c => new ListItem(c.Id, c.Name)).

In entity framework there should be a way to eager load (include) navigation properties of a derived class.

When in an data model for entity framework has a navigation property it is not posseble to eager load that navigation property besides when using OfType<> or when eager loading the derived type itself by a navigation property.
This could be done by using a special syntax of the include path.
Since a property of the base class can not have the same name as the derived class, it would also be possible to navigate to the derived class by its name.

e.g.: If class Derived inherits from Base and has a navigation property named Prop one could say
dbContext.BaseSet.Include("Derived.Prop")

this should query all entities of type Base and eager load property Prop for all instances of Derived in the reslult list

Entity Framework should support automatic deletion of orphan records, the way "all-delete-orphan" works in NHibernate.

If I have a one-to-many relationship between Orders and OrderLines, and code inside the Order class calls OrderLines.Remove(orderLine), this should cause the order line to be deleted when I save changes. Currently, EF attempts to set the order line's OrderID to NULL. If the OrderID column is non-nullable, the update fails with a constraint violation error.

I found this forum post in which Daniel Simmons from Microsoft says EF doesn't support this: http://social.msdn.microsoft.com/forums/en-us/adodotnetentityframework/thread/CB9C1C4A-DF12-44E4-B00A-417C80BF5453

This is an important feature for an ORM, since it's difficult to cleanly work around it. One workaround is to add a call to context.OrderLines.Delete(orderLine) immediately when an order line is removed in memory. But the Order aggregate should be able to manage its order lines without taking a direct dependency on the ORM.

Make Entity Framework Fully Mockable and injectable

In general, mocking out the Entity Framework DAL is a big pain to accomplish. ObjectContext has no interface and the T4 templates aren't written to create interfaces for the objects they create.

This hampers good unit testing and makes them less injectable.

Put an interface on ObjectContext. Have the T4 Templates put interfaces around all of the objects that are generated and make sure that all objects used have interfaces so that mocking frameworks, like MOQ or Moles & Pex can automatically generate stubs to replace the objects in unit tests so that tests don't need to be tightly coupled to the database.