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)).

I supposed that eager loading currently supports only single fixed strategy and except some rare cases this strategy always joins all eager loaded data to one huge record set - at least that is what I saw so far.

I described the impact of such eager loading on Stack Overflow: http://stackoverflow.com/q/5521749/413501

It would be nice to have some control over the way how eager loading is executed with possibility to define if eager loaded data should be joined into single result set with the main data or if they should be executed in separate query.

Something like:

var data = context.Items
.Include(p => p.ParentItem, EagerLoadingStrategy.JoinQuery)
.Include(p => p.SubItems, EagerLoadingStrategy.SeparateQuery);
.Where(p => p.Id == 123);

Generated SQL executed in single roundtrip (the main difference between using separate LINQ queries) will look like:

/* Base item query with joined parent */
SELECT i.Id AS ...,
i.ParentId AS ...,
i.Name AS ...,
p.ParentId AS ...,
p.Name AS ...,
FROM Items AS i
LEFT JOIN Items AS p ON i.ParentId = p.Id
WHERE i.Id = 123

/* Separate query for children */
SELECT c.Id AS ...,
c.ParentId AS ...,
c.Name AS ...
FROM Items
WHERE c.ParentId = 123

It would be also nice to be able to set default strategy globally per context instance.

At the moment I'm not sure if there is another useful strategy for the eager loading but perhaps a community will find another.

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.

Some times, depending on how you design your model, you want a certain navigation property to be loaded *always*. It's static part of the model just like the (implicit) lazy load nature of a virtual navigation property when lazy loading is configured.

There should be a way to define eager load for navigation properties, something like:

[Include]
public ICollection<Item> Items { get; set; }

and/or via DbModelBuilder:

modelBuilder.Entity<Order>().Property(x => x.Items).Include();

This would greatly simplify client code as it wouldn't have to include on each query/access, and it would also work with Find(key). This would make it more suitable to DDD-style design of entities (so called aggregate roots).