I spend a huge amount of time to bend the Entity Framework to my needs and can therefore say, that it fulfills most of the requirements you want from an ORM. But some aspects are far too complex, as other ORMs have shown that it can be made easier.

For example, getting started with the Entity Framework is fairly easy, since you can just fire up the Designer in Visual Studio and have a working ORM in a matter of minutes. But you end up with Entity-Classes tied to the ObjectContext created by the designer (this can be avoided using a custom T4 Template). This is not necessarly a bad thing, but it's that kind of Microsoft "Getting Started" approaches, that you don't want to use in a real application.

But if you dive deeper into the Entity Framework you can see, how you can avoid most of it's pitfalls: The Designer generates an EDMX file, which (if you look at it in an XML editor) is nothing more than a combination of the three main aspects of an ORM, the physical storage (your database), the conceptual model (your entity classes) and the mapping between both of them. The custom build-action applied to .edmx files in Visual Studio will split those 3 parts into three separate files and adds them to the assembly as embedded resources. When creating an ObjectContext the path to those three files is used in the ConnectionString (which always looks a bit confusing to me). What you can actually do here, is do all this by yourself. This means writing the storage schema, conceptual model and mapping in an XML editor (much like NHibernate) and embed these to the assembly containing your model.

The base Entity Framework base class "ObjectContext" can than be constructed from those three files (it takes an MetadataWorkspace and EntityConnection) but the point is, that you have full control over how the ObjectContext get's created. This opens the door for a lot of functionality you might not expect from the Entity Framework. For Example: you can embed m