The fundamental problem with these kinds of "solutions" is that the object model and the relational model are fundamentally different in a way which precludes a simple/semi-automatic mapping method between them except in the degenerate cases where either the relational side is not really relational (being derived from the object model) or the object side is not really object-oriented (being derived from the relational model). So, the short answer is a plague on both your houses.

Back in the 70's in a publication called "New Musical Express" there was a cartoon strip called "The Lone Groover". One strip has stayed with me, partly because as the years go by I identify more and more with the hero. It features the Lone Groover's first encounter with punks. He is pictured, dressed as a cowboy, leaning up against a bar looking down on a couple of scrawny characters with spikey hair and small bits of metal sticking out of various bits of their faces. His speech bubble says simply "I was wearing a Javanese fish-hook through my foreskin before you were born, laddie".

I remember back in the 80's a product called "The Last One" (http://www.tebbo.com/presshere/html/wf8104.htm) which was going to make computer programmers redundant by allowing computer-illiterate managers to specify programs via flowcharts whereupon "The Last One" would generate the program for you. "The Last One" was so called because it was going to be the last hand-crafted human-written computer program.

A few years later I remember the hype surrounding proveable program development. This was the idea that you somehow fed your requirements into this program and it would generate tests to comprehensively test your program. I don't remember anything useful actually being developed (if it had then testers would be out of a job) rather it was some sort of academic project.

What all of these things have in common is that they try and offer automated solutions to what are very difficult problems. What makes the problems difficult is the same sort of thing which makes the traveling salesman problem difficult, namely that as the problem set grows bigger the solution set increases at a polynomially related rate. In short these "solutions" are essentially useless. In the practical world we don't want an exact solution. We want a solution which is good enough.

When I test a program I don't want to test all possible routes through the program, I want to test the routes which are going to be exercised in real life. If there is a bug in a path which is never going to be exercised then who cares?

In the same way, generating a suitable relational model from a given object model is not something which can usefully be automated. Any such "solution" to a real-world complicated example is likely to be unmaintainably large, complex, unrepresentative and useless. In the real world a relational model has to be capable of being tweaked when the object model changes. That means not having to run some program or process to auto-generate the relational model afresh.

From what I can see the "Vote of No Confidence" paper is more accurately a vote of no confidence in the whole automated ORM process. What is hilarious is that in their rush to express their dismay that basically they weren't consulted they've ended up condemning their own efforts as well.

The EF concentrates too much on the data aspects of ORM and ignores the behavioural aspects? Of course it does. Objects have behaviour as well as state but relational entities have state and relationships, no behaviour. The criticism is valid of the ORM process in general not just the EF.
The EF doesn't handle lazy loading very well? Of course it doesn't. That isn't something which can sensibly be automated. It depends on business rules which are always going to be different for each application. And so on.

Having said all that, I am at the end of the day a contractor and I fully recognize these efforts (NHibernate and the EF) for what they are, namely job-creation schemes. They have tremendous potential to generate massive amounts of (unecessary) work both during initial development and, more crucially (typically 90%+ of the work done on a successful project is done during maintenance) during maintenance. If asked about the use of these tools during my day job I will salve my conscience by expressing the opinion that there are probably better and more efficient, albeit more intensive in terms of intellectual requirements, ways of doing these things but that at the end of the day I am happy to go along with them.

In order to try to make sense of the petition, I have reduced it to plain English, and taken out every sentiment that seemed irrelevant. It was a revelation. For the benefit of anyone else who is struggling with making sense of it, here is my precis.
------------------------------------------------------------------------------------------


We’re experts in entity-based applications. We like the idea that Microsoft will provide a framework for entity architectures, but we are worried about Entity Framework itself.

We want to work with Microsoft on entity architecture applications. We want to see entity-oriented applications succeed on the .NET platform.

We want the Entity Framework to be really good

Microsoft need to get the product out on time

We think Microsoft is right in calling us “the technical community’s best and brightest,” We’re clever, and we want to help.  We have lots of experience with entity-based applications with .NET. too.

ADO .NET Entity Framework in its current state is not good because.
• The Entity Framework has concentrated on  the data storage aspects of entity objects, whereas we think that they should have concentrated on making  it possible for objects to follow business rules and business logic. We think the latter is more important
• We don’t want to have to think about the realities of the manipulating large quantities of data. Surely this can be entirely automated?
• We don’t like shared data models. We like lots of them.
• We think it is a good idea to put  business logic in the entity classes. We hate the idea of business logic being in the database.
• It is difficult to test applications written with EF, independently of the database.
• SubVersion and other merge-based source control doesn’t work easily with applications written with  EF