I was reading through what is actually a reasonable comparison of EF to other technologies on Dan Simmons' blog.
Dave, Jeremy, and Jimmy have already discussed many issues but ...
One bit caught my attention:
Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc. Not only does this increase the value of the data model by allowing it to be reused for many parts of your overall solution, but it also allows us to invest more heavily in common tools which will streamline the development process, make developer learning apply to more scenarios, etc. So the differentiator is not that the EF supports more flexible mapping than nHibernate or something like that, it's that the EF is not just an ORM--it's the first step in a much larger vision of an entity-aware data platform.
DDDD is something very similar to this but I think they have completely missed the boat. I have a single slide in my deck from devTeach that summarizes my objections quite succinctly.
I have since rewritten this slide to be more generic in "A single model cannot possibly be appropriate for all facets of your application including transactional behaviors, searching, and reporting"
In DDDD I deal with this by recognizing that the Entity is of limited importance and should be different in different places ... It is what happens to the entity that REALLY matters and it is the recognition and the making explicit of EVENTS in the domain that allows you to easily support multiple concurrent parallel models. These events should not be automatically generated object->field changed messages but should be DOMAIN CONCEPTS.
let me say for the 1000th time. If you are reporting off your transactional model you are seeking trouble!
On the DDD list people often ask "How do I use my domain to report" ... the answer "You don't" they are different models with different goals. It pains me that MS intends to push people into what is an anti-pattern, even for small systems.
Jimmy Bogard was also right on the money when he mentions that I should not expose my model outside of my Bounded Context. I highly doubt a system like EF and what they suggest would work beyond trivial cases and is (as proposed) one small step up from using sprocs and linked servers as your integration model.
I could say MUCH more about this but instead I will try to rework my talk a bit in Victoria Wednesday to try to include some of this.