One of the great improvements to the .NET 3.0 framework was the introduction of the LINQ (Language Integrated Query) technology that allows developers to make direct calls into a data store (likely a relational database, but not always) using language primitives.  This advance moved data access into the first tier of programming by embedding it into the .NET language technologies.  Instead of using a seperate and non-integrated technology, LINQ offered developers a way to write data access code faster, simpler and, hey, just way more cool than before.

Together with LINQ, extensions were created among them LINQ-to-SQL which allowed LINQ to bind to a relational database like SQL Server.  Really cool technology and one which a lot of teams using .NET are rapidly embedding into their applications.  

Then Microsoft rained on the parade.

For reasons unknown, Microsoft announced that the newly updated Entity Framework will be the recommended way to perform data access using LINQ in .NET 4.0 despite many voices shouting that this is the wrong way to go.  Now we all know what "recommended" means - it's code for "anything else you're doing than this is DOA".  Essentially, if you're using LINQ-to-SQL, you're using technology that although supported (for now) is no longer the recommended way to do data access.

 So what is Entity Framework?  If you have experience in the Java world, think "Hibernate" or "JPA".  These are technologies that abstract away almost completely any notion of the underlying data store technology.  You set/get/delete entities representing the objects in your application.  If you need to drop down inside the technology to do some low-level data access, it usually provides a means to do so by direct SQL injection, etc.  But the application code you write has no SQL in it - it's abstracted away by the data access technology.

 From an architects point-of-view, this is ideal.  Why force developers to learn messy SQL when they can just use C#, VB.NET, etc and write objects that know how to persist themselves?  However, architects often have a tendency (especially in the software space) to convince themselves that something is good because it seems elegant.  So we begin with SQL which is itself an abstraction of accessing the database to LINQ to Entity Framework.  We're moving farther and farther away from the data store in an attempt to keep developers away from perceived nastiness in saving (and loading) data.  

Ask yourself this question - how many high-performance Web 2.0 sites out there routinely use high-level data access abstraction technologies (beyond stored procedures) ?  Likely zero. 

Frameworks like EF are great at solving certain types of problems particularly where performance is not a great concern, where there is no underlying relational engine, and so on.  But a .NET developer writing line-of-business applications using SQL Server doesn't have  those problems.  He simply wants to write code really fast, that works right the first time, and helps him deliver business value ever faster to his users. 

With the rapid rise in competition from Google GWT, Adobe Flex, Ruby, and the myriad of Java technologies, the choices of how to build an application are ever more available.  Hopefully Microsoft will consider whether they are helping developers become more productive, or helping developers consider other options.

 Let's hope its the former.