I have to say that I'm pretty disappointed with the ADO.NET Entity Framework from what I've seen of it. The few readers that know me personally know that I am extremely opinionated about data access layers & O/R Mappers. The connection strings required for ADO.NET Entity Framework based projects are horrendous. How horrendous? How about an example:
<add name="MyProjectEntities" connectionString="metadata=.\MyProjectDataModel.csdl|.\MyProjectDataModel.ssdl|.\MyProjectDataModel.msl;provider=System.Data.SqlClient;provider connection string="Data Source=SERVERNAME;Initial Catalog=MyProject;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
Then there's the lame requirement to include in the project output (bin folder) the 3 metadata files listed in the connection string (MyProjectDataModel.csdl, MyProjectDataModel.ssdl, MyProjectDataModel.msl).
So my gut feeling is this is not developer-friendly. I'm trying really hard not to blurt out "Wow, this totally sucks." I'll still learn it because clients will ask for it, but I'm going back to LLBLGen Pro for my own project. The appeal that the ADO.NET Entity Framework had for me (over LLBLGen Pro) was that if I chose to provide my clients with the source code to my application(s), they would not need a 3rd party license for the O/R Mapper. But if my initial impression of the ADO.NET Entity Framework is correct (more complicated to setup than necessary), it doesn't make a whole lot of sense to use it.