O Entity Framework - EF, é um conjunto de tecnologias da ADO .NET que permite aos desenvolvedores a criação de aplicações persistentes através da programação direcionada a um modelo conceitual ao invés da programação direcionada diretamente a um banco de dados relacional, eliminando a maioria do código de acesso a dados que os desenvolvedores precisam escrever em suas aplicações.
O Entity Framework possui portabilidade para os mais variados bancos de dados, concorrendo diretamente com o NHibernate. Ele tem como diferencial as várias ferramentas visuais e recursos nativos do Visual Studio, sendo a referência da Microsoft no contexto do mapeamento objeto/relacional.
Principais benefícios:
- Aplicações podem ser construídas com base no modelo conceitual, incluindo tipos com herança, membros complexos e relacionamentos entre si.
- Aplicações não dependem mais de códigos e estruturas presentes na camada responsável pelo armazenamento de dados.
- Os mapeamentos entre o modelo conceitual e o schema de armazenamento pode ser modificado sem que o código da aplicação precise ser alterado.
- Desenvolvedores podem trabalhar com um modelo de objetos consistente que pode ser mapeado para vários schemas de armazenamento e implementado em banco de dados diferentes.
- Multiplos modelos conceituais podem ser mapeados para um único schema de armazenamento.
Uma das abordagens de design mais comuns nas aplicações de hoje é a divisão da aplicação em 3 partes: modelo conceitual, modelo lógico e modelo físico.
- Modelo Conceitual: Define as entidades e relacionamentos no sistema.
- Modelo lógico: Consiste em normalizar as entidades e relacionamentos em tabelas e chaves em um banco de dados relacional.
- Modelo físico: Aborda as capacidades de um engine de banco de dados em particular, especificando detalhes de armazenamento, tais como particionamento e indexação.
O modelo físico geralmente é gerenciado pelos DBAs, no intuito de melhorar a performance do banco de dados, os progamadores no entanto limitam-se a trabalhar na definição do domínio e do modelo lógico, escrevendo querys e stored procedures.
Muitas equipes de desenvolvimento preferem, ao invés de criar o modelo conceitual primeiro, começar o desenvolvimento a partir do modelo lógico, criando as tabelas e chaves no banco de dados. O maior problema desta abordagem é que não existe na aplicação nenhum tipo de controle que garanta que as modificações feitas no modelo conceitual serão refletidas no banco de dados.
Quando o Entity Framework foi lançado com o SP1 do .NET 3.5, os desenvolvedores passaram muito feedback sobre melhorias e correções. A microsoft recebeu este feedback e trabalhou muito para melhorar o Entity Framework no .NET 4, uma dessas melhorias será discutida neste artigo: POCO SUPPORT (PLAIN OLD CLR OBJECTS)
POCO vem do termo POJO - Plain Old Java Object - utilizado pela comunidade Java. São classes que não implementam interfaces específicas de um framework, mas podem implementar métodos e comportamentos. O problema das classes possuírem dependências de algum framework específico é a dificuldade em testá-las e dar manutenção, torna-se muito complicado utilizar estas classes em outros projetos. Com a utilização de classes POCO esse tipo de problema não ocorre.
O desenvolvimento "Code-First" traz para os desenvolvedores os seguintes benefícios:
- Para definir os objetos de modelo, basta escrever classes simples, sem a necessidade de classes base
- Permite a persistência de banco de dados sem que seja necessário configurar nada explicitamente
- Opcionalmente, substituir a persistência baseada em convenção e usar uma API de código fluente para personalizar completamente o mapeamento de persistência.
Para habilitar o "Code-first" no Entity Framework você precisa fazer o download de uma biblioteca a parte ( http://www.microsoft.com/en-us/download/details.aspx?id=18116 )
Agora vamos a um pequeno exemplo prático do funcionamento das classes POCO e da biblioteca System.Data.Entity.CTP:
Vamos criar um projeto chamado CodeFirstSolution e adicionar uma camada chamada DataAccessLayer que contém as classes listadas na imagem abaixo:
Repare que o nosso modelo contém 2 entidades: Livro e Autor. Existe um relacionamento de 1 para N entre as duas.
Além das nossas duas classes POCO definidas (Livro e Autores), vamos criar uma classe para adiministrar a persistência dos objetos no banco de dados. Vamos chamar a classe de "Contexto". Repare que ela é herdeira da classe base DbContext.
As classes DbContext e DbSet usadas fazem parte da biblioteca Code-First. Você precisa adiconar uma referência a dll System.Data.Entity.CTP que foi instalada no diretório" \Arquivos de Programas\Microsoft ADO.NET Entity Framework Feature CTP5\Binaries" para referenciar essas classes. Após adicionar a referência, inclua a diretiva “using System.Data.Entity” na sua classe.
Agora vamos adicionar uma nova camada, um projeto do tipo Console Application, para testar o nosso modelo conceitual e verificar a criação do banco de dados a partir do código.
Após adicionar a camada ConsoleTests, adicione um arquivo app.config que contenha uma connection string apontando para o servidor do banco de dados. Repare que a connection string deve ter o mesmo nome da nossa classe "Contexto" (padrão do entity framework).
Adicione as propiedades "Trusted_Connection=False;Persist Security info=True;" a sua connection string caso você receba o seguinte erro: "".This operation requires a connection to the 'master' database. Unable to createa connection because the original database connection has benn opened and credentials have been removed from the connection string."
Agora vamos escrever um programa para inserir um novo livro na base de dados. No nosso caso, o banco de dados nunca foi criado, quando executarmos a aplicação o Entity framework vai se encarregar de gerar o schema do banco de dados com base na connection string informada.
Após executar o programa, podemos verificar o banco de dados criado automaticamente:
Repare que o Entity Framework além de criar as duas tabelas que definimos com as classes POCO, também criou a tabela EdmMetadata, responsável por manter o registro dos modelos usados para gerar o banco de dados. Caso haja alguma modificação nos modelos, o entity framework saberá com base nos dados desta tabela.
As chaves necessárias para estabelecer o relacionamento entre nossas entidades também foram criadas automaticamente:
Nas grandes empresas, os processos de desenvolvimento são o que garantem a sincronia entre a aplicação e o banco de dados. Geralmente o desenvolvedor precisa preencher algum tipo de formulário que será encaminhado ao DBA para que este possa realizar a alteração necessária. Agora imagine que por algum motivo, a alteração feita e testada no ambiente de desenvolvimento só recebeu autorização para ser publicada em produção um ano depois. É preciso que o DBA tenha acesso ao mesmo formulário enviado pelo programador um ano atrás, caso contrário os requisitos da alteração não podem ser atendidos.
Como podemos estabelecer um controle entre a versão do modelo lógico gerado automaticamente e o modelo conceitual que definimos na nossa aplicação? O EF é capaz de apontar qualquer alteração feita no modelo conceitual desde que o banco de dados foi gerado pela última vez, a partir da tabela EdmMetadata.
Para verificar este controle, vamos voltar ao exemplo e modificar a classe Autor para incluir a propriedade Cpf, como mostra a figura abaixo.
A mensagem nos diz basicamente que temos as seguintes opções:
Atualizar o banco de dados manualmente.
Excluir o banco para que ele seja recriado pela aplicação.
Deixar que o Entity Framework seja responsável pelas atualizações necessárias.
Vamos alterar o código do nosso programa para fazer com que o EF atualize o banco de dados automaticamente. Adicionamos apenas uma linha de código, como mostra a figura abaixo.
Fontes:
http://www.macoratti.net
http://msdn.microsoft.com
http://weblogs.asp.net/scottgu
No comments:
Post a Comment