I know this is probably too late for the original query, but for the sake of future people with a similar question...
To my mind, the crucial aspect is whether you're doing an entirely new project or working with a legacy DB. I'm working with a legacy DB, with some rather idiosyncratic design decisions. I'd like to use EF, but it simply failed to map over these idiosyncracies, while L2S managed perfectly well.
For example. Some of the FKs contained other values than keys to related rows - effectively doubling as an FK/flag column.
Further, the FK inheritance mapping totally failed against out DB, so I opted for a flat L2S model, to get the benefits of type-checking and name checking at query time, but ended building my own mapping layer.
All of this is a horrible pain, if its any consolation to MS, I also found NHibernate incapable of the task. In my experience, in real-world usage too many DBs have these kind of issues, hence my recommendation that EF is not really suitable for brown-field develop ment.
For new projects, you have the luxury of evolving your DB design to match the assumptions of the framework. I can't do that as existing applications rely on the data design. We're hoping to improve the design incrementally, but attempting to correct all the problems up front would result in an infeasibly large migration event (for our resources).
Note: In the UK (at least), brown-field development is building houses on land that has previously been developed. Green-field development is building on our dwindling resources of countryside. I've reused the terms here.
answered 2012-12-12T17:05:44.687