ADO Entity Framework - Parte 1
Introdução ao ADO Entity Framework
O EF faz parte da família "ADO" que visa uma modelagem dos dados de forma mais abstrata, mais conceitual, buscando evitar as limitações atuais do modelo de desenvolvimento relacional.
O principal foco é que você consiga desenvolver sua aplicação acerca do problema real, através de um nível mais alto e conceitual, e não tenha que ficar limitado ao modelo relacional. O objetivo não é que você deixe de criar suas tabelas, campos, etc., mas que seu modelo lógico seja puramente conceitual.
Atualmente, por melhor que seja o modelo conceitual de desenvolvimento em algum momento teremos limitações devido ao modelo relacional, já que a maioria dos O/R baseia-se no schema da base de dados.
Seguindo o próprio "Overview" do EF vamos ilustrar um problema:
Se eu quisesse saber o nome dos funcionários com salário acima de R$ 100,00 eu teria uma query assim :
select p.Nome from funcionario f
inner join PessoaFisica pf on f.FuncionarioId = pf.PessoaFisicaId
inner join Parceiro p on pf.PessoaFisicaId = p.ParceiroId
where f.Salario >= 100
Enquanto a necessidade lógica real esta acerca dos "funcionários" ainda assim é necessário estar ciente de que o "nome" do funcionário esta em outra tabela devido a normalização física.
Este é um problema clássico da impedância causada entre o modelo lógico e sua representação fragmentada física e relacional.
Vários O/R já removem, em parte, essa impedância, permitindo que seu modelo lógico seja diferente do modelo físico relacional.
Mas então, em que o EF faria diferente?
Em termos pragmáticos, com o EF suas queries funcionam sobre o modelo conceitual e com os outros O/R suas queries são sempre mapeadas para o modelo relacional.
Claro, para o EF trazer dados ele terá que efetuar em algum momento uma query na base de dados, mas isso não é impedância para sua query conceitual.
Imagine que você criou um campo em sua classe que não existe na base de dados, ex: NomeCompleto que é a concatenação dos campos "PrimeiroNome" e "UltimoNome" que existem na base. Você conseguiria fazer uma query utilizando este campo "NomeCompleto" ? Acredito que não! No momento em que o O/R tentasse mapear esse campo em uma query iria falhar, pois o mesmo não existe na base.
Pergunta: Será que o EF permite isso?
Modelando os Dados Conceituais: Entity Data Model
O EDM é a representação conceitual dos dados ( schema ) através de um modelo de abstração mais alto.
Os itens do EDM são:
Entity : É uma instância de um Tipo no EDM ( Entity Type ) [ Parceiro, PessoaFisica, Funcionario ]. Entities são agrupadas em Entity-Sets.
Relationship : É uma instância de um Tipo de Relacionamento no EDM ( Relationship Type ). Relationships são agrupadas em Relationship-Sets.
Este modelo de abstração permite ao desenvolver especificar melhor seu modelo conceitual, como por exemplo a criação de campos de tipos não suportados no modelo relacional. Já imaginou ter um campo que fosse uma enumeração e ainda poder criar queries sobre ele?
Isso responde a primeira pergunta mais acima.
Agora, se seu modelo conceitual é diferente do modelo físico relacional como o EF fará essa transposição de dados entre ambos?
...próximo post !
Referências:
http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx
http://gupea.ub.gu.se/dspace/bitstream/2077/10462/1/gupea_2077_10462_1.pdf