Programando contra um modelo e não contra um banco de dados

A ADO .NET Entity Framework representa um verdadeiro terremoto no paradigma de desenvolvimento de aplicações com banco de dados relacionais.

Antes do lançamento da release final com o service pack 1 do Visual Studio 2008 a estratégia da Microsoft para acesso a dados aparentemente estava centrada nos DataSets. O advento do LINQ  prenunciava que mudanças estavam a caminho e com o LINQ to SQL, um aperitivo para o SQL Server, pudemos vislumbrar o que a ferramenta poderia realizar. Depois de várias versões betas chegamos a esta versão mais madura do Entity Framework.(Com certeza terá que amadurecer mais ainda)

O fim do LINQ to SQL - uma morte anunciada:  (Microsoft kills Linq to SQL)
Estará realmente o LINQ to SQL com os dias contados ?  O LINQ to SQL irá se tornar um projeto Open Source ?
A cada dia que passa o LINQ to SQL é visto como uma solução temporária. A Microsoft tem um histórico de já ter descartado diversas tecnologias de acesso a dados e por que agora seria diferente ?

Usar o LINQ to SQL com certeza é mais fácil do que o Entity Framework.
Como o Entity Framework não é específico para um banco de dados obter um desempenho otimizado para outros banco de dados como Oracle, MySQL não é uma tarefa simples para seus fabricantes.

Talvez a resposta para esta pergunta neste momento esteja no passado. Veja o artigo: The Origin of LINQ to SQL

Usando os DataSetes, DataReaders e outras tecnologias de acesso a dados gastavamos nosso tempo indo até o banco de dados para realizar consultas, obtendo o resultado e populando nossas classes com as informações obtidas.

Com o Entity Framework não temos que realizar consultas contra um schema de um banco de dados, antes efetuamos consultas contra um schema que reflete o nosso modelo de negócio; quando os dados são retornados eles já são retornados como objetos, não temos que efetuar nenhuma conversão; quando precisamos salvar as alterações de volta no banco de dados salvamos os objetos e pronto. O Entity Framework efetua todo o esforço necessário para traduzir os nossos objetos de volta às linhas e colunas existentes no mundo relacional, de forma muito similiar a maneira que muitas ferramentas ORM, como NHibernate trabalham.

O Entity Framework usa um modelo chamado Entity Data Model (EDM) o qual emergiu gradualmente a partir do Entity Relationship Model (ERM) - um conceito originado a partir do modelo apresentado pelo Dr. Peter Chen na publicação 'The entity - relationship model — toward a unified view of data'  em 1976 , o qual você pode consultar neste link: http://csc.lsu.edu/news/erd.pdf

O Entity Data Model(EDM): um modelo de dados do lado do cliente

Um EDM é um modelo de dados do lado do cliente e pode ser considerado o coração do Entity Framework. Ele não é a mesma coisa que um modelo de banco de dados que pertence ao banco de dados. O modelo de dados na aplicação descreve a estrutura dos objetos de negócio.

O EDM fornece um schema conceitual , uma representação do banco de dados, um arquivo de mapeamento e o acesso a um provedor ADO .NET do Entity Framework para o banco de dados de destino, assim, o Entity Framework não se importa qual o banco de dados esta sendo usado. Ele fornece um modelo comum para interagir com o banco de dados, com uma sintaxe de consulta comum e métodos comuns para enviar as alterações de volta para o banco de dados.

Vejamos as seguir os recursos mais importantes do Entity Framework:

Além disso , como o modelo de classes é gerado automaticamente, pequenas alterações no modelo não terão grande impacto na sua aplicação, pois modificar o modelo é muito mais simples do que modificar os seus objetos e o código de acesso a dados sob o qual ele se baseia.

Eu sei é apenas Entity Framework, mas eu gosto...

Referências:

José Carlos Macoratti