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.

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

It's unfortunate not to be able to mark interfaces for EF mapping (code first). This will allow to really abstract the implementation. Allows a unique representation of the data in the context of RIA Services (if Ria Services allows also for interface 'mapping'). This won't be very hard to implement since EF is happy when it subclasses... For the benefits: imagine you have only interfaces to declare your model. On the server side, you use EF to get your interfaces 'filled' from DB. on the client side you get those same interfaces filled by RIA services... You can reuse any algorithm against your data.
I am not sure this idea will be implemented one day. If it is then I have many other ideas to enhance its usage...

A problem encountered when an entity is instantiated using non-ef infrastructure, e.g. ASP.NET MVC model binder mechanism. Such entity is pure poco class without proxy. Updates of relationship of the entity can be only synchronized using manual approach according to MSDN(and proven by experience)
http://msdn.microsoft.com/en-us/library/ee373856.aspx "If you are working with disconnected objects you must manually manage the synchronization."
Manual synchronization is really painful approach and really not a good ORM style solution.
The problem even becomes critical for me in decision to migrate my application to nhibernate due to the fact that nhibernate can do such synchronization without problems http://www.codinginstinct.com/2009/11/nhibernate-feature-saveorupdatecopy.html
Detailed description of the problem:
http://stackoverflow.com/questions/3635071/update-relationships-when-saving-changes-of-ef4-poco-objects

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.