There is some controversy going on regarding the need for Entity Framework when LINQ to SQL provides much of its functionality.

Now, I'm far from being a fanboy of OR/M products, and usually I tend to stick to the good-ol' dataset (and that's another story), but actually I do see a strong case for EF over the other tools. LINQ to SQL is a real OR/M product, just like NHibernate et al., while EF is, simply put, not.

An OR/M tool actually tells you: "Listen, bro. You just tell me what your database looks like and who is its vendor, I'll take care of the rest. Oh, and if you want to change the vendor - don't worry, you won't need to change a single line of (compiled) code  for this.". Some tools deliver this promise better, some worse,  but that is the main idea.

And that is exactly NOT the main idea of the EF. What it tells you is something else: "Listen, bro (this part is the same). I really don't mind what your database looks like. I want to know what you want your object model to look like. You take care of this first, and then we will handle the database." The database in EF is almost an afterthought, Something that should be taken care of because our object model should be saved somewhere, but its structure does not affect our model. I believe this is the right approach even though the tools may mislead you - they allow you to generate the entities right from the database, and not vice versa, but again - we're only on Beta 2.

So in OR/M the database starts it all, while in EF its role begins after the actual design ends. Of course, this does not mean that the DBAs should start revising their CV. There is a lot of work to be done in the database, only this work belongs now to what the database really should do - handle the data fast, securely and reliably, and not dictating how our objects look like.

Here is an actual example that will help clarify my point of view: I'm currently involved in a large project which utilizes Oracle 10g and SQL Server 2005. The application will work in the following 4 years with the Oracle, and then switch to the SQL (presumably 2008 by then). The ERD of these databases has some differences. Using EF, we can design our application with database-agnostic approach, define the mapping according to the Oracle ERD, and when time comes switch only the mapping files (actually, there is no mapping-dedicated file, it all resides in the same XML, but you've got the idea...) without modifying the application. Convenient, he?

Well, yes it is, but there are two caveats to this approach:

1. There is not yet an Oracle provider for EF. There will be, they even said that here, but I don't know when.

2. There is no go-live license for EF.

Since both those problems are temporary (I hope, at least...), I think it will be really interesting to test this in the field.

BTW - The opinions expressed here are solely mine. I'm not pretend to represent the official Microsoft position on this subject.