Introdução ao Entity Framework Code First Migrations

 

Para quem já conhece o EF (Entity Framework) com a utilização do Code First (Código primeiro) sabe como era incomodo ter que recriar o banco toda vez que realizasse uma nova alteração no modelo, isso a título de desenvolvimento. Com o pacote EntityFramework.Migrations disponibilizado no EF 4.2 é possível melhorar este cenário permitindo o desenvolvedor ter um controle maior do modelo do banco de dados, no qual permitirá até criar versões dos modelos gerados pelo EF.

Normalmente se utilizava classes de inicialização que recriavam o modelo do banco. Algo como:

context.Database.CreateIfNotExists();


Com isso o banco era recriado toda vez que encontrasse uma alteração no modelo de código ao comparar com os dados que são informados na tabela EdmMetadata que também era necessário. Na imagem abaixo é possível ver a tabela que é criada automaticamente pelo framework para seu controle.

 



EntityFramework.Migrations


No EF 4.2 não necessitamos criar uma classe de inicialização ou ficar recriando o banco de dados, apenas iremos gerar versões de nosso modelo e atualizar o banco para a versão desejada inclusive mantendo os dados existentes.

 

Para utilização da migração é necessário possuir obviamente o pacote EntityFramework e também do pacote EntityFramework.Migrations. Se você não possui os pacotes adicionados em seu projeto, acompanhe os seguintes passos da instalação através do NuGet que é uma extensão do Visual Studio e possui um console com diversas funcionalidades, dentre elas, baixar pacotes diretamente para seu projeto de maneira muito simples.


Com o NuGet instalado vá em: Tools –> Library Package Manager –> Package Manager Console



Você verá esta tela que é o console do Nuget. Para nosso exemplo, crie um projeto qualquer, irei demonstrar com um simples projeto Class Library de nome “DevBrasil”como mostrado abaixo, duas classes ainda sem relacionamento e o nosso contexto que não será explicado neste artigo, pois não é nosso objetivo e espera-se que o leitor conheça um pouco de EF.

 

Explicando apenas o “modelBuilder.Conventions.Remove<IncludeMetadataConvention>();” esta linha é adicionada para remover a necessidade da tabela EdmMetadata como mostrada no início e assim termos uma maior independência do controle do framework.


Importando os Pacotes Necessários 

Agora vamos adicionar os pacotes do EntityFramework e EntityFramework.Migrations ao nosso projeto.

 

Abra o console do NuGet e verifique primeiramente se o Default Project é o que você está utilizando e no console digite:

Install-Package EntityFramework” e digite enter.


Você verá o processo de instalação e logo depois de obter a mensagem de confirmação:

“Successfully installed 'EntityFramework 4.2.0.0” e

“Successfully added 'EntityFramework 4.2.0.0' to DevBrasil”

Você pode conferir na pasta de referências se foi devidamente baixado conforme a figura a seguir.



Realize o mesmo processo para a instalação do pacote EntityFramework.Migrations pois ele ainda não está disponível dentro do pacote EntityFramework o que deverá acontecer futuramente assim como o EntityFramework também fazer parte do .Net Framework. Ao instalar o pacote no projeto é criada uma pasta chamada “Migrations” contendo um arquivo “Configuration.cs” como podemos ver na imagem abaixo da nossa solução.


 

Na imagem acima podemos ver a estrutura do arquivo “Configuration.cs”, por enquanto iremos apenas adicionar o contexto onde é indicado na primeira marcação e no construtor setamos uma propriedade “AutomaticMigrationEnabled” como false para mantermos mais controle ainda em nossas migrações sendo necessário gerar para cada modificação uma versão diferente. E removerei o comentário da segunda marcação para ficar mais limpa a classe. A imagem a seguir ilustra como ficará.

 

Agora vamos criar nossa primeira versão do Contexto (modelo) criado. Abra o console do NuGet e digite:

“Add-Migration PrimeiraVersao” e digite enter.

Será criada uma classe com o nome “PrimeiraVersao” com algumas informações relevantes no inicio. Essa classe contém dois métodos: Up e Down.

  • Up: Método chamado quando é feita o Up-grade do banco ao solicitar a migração da versão.
  • Down: Método chamado quando a classe é chamada como Down-grade caso já exista uma versão gerada posteriormente em uso.



Com a nossa primeira versão gerada só nos resta atualizar o banco, como não foi setado nenhum banco padrão no contexto, o Visual Studio fará com que seja criando no banco local, caso exista é claro. Para atualizar devemos abrir o Console do NuGet e digitar:

“Update-Database -TargetMigration:"PrimeiraVersao" –Verbose” e digitar enter.

Não é necessário digitar todo esse comando para se realizar uma atualização, na verdade só é necessário o “Update-Database” o “-TargetMigration” serve para nos garantir para qual versão estamos migrando, inclusive é com ele que realizamos down-grade, basta informar o nome da versão desejada. E “-Verbose” serve para exibir todo SQL que é executado dentro do próprio console do NuGet, então acho uma boa prática utilizar a atualização desta maneira.

 


Na imagem a seguir podemos ver o banco que foi gerado. A tabela foi gerada com nome “Opcaos” pela pluralização do Entity Frameworkque pode ser contornado quando as classes forem bem configuradas, o que não é nosso caso aqui.



Para testar uma atualização adicione na classe “Pessoa.cs” a propriedade:

public List<Opcao> Opcoes { get; set; }


E gere uma nova versão chamada “SegundaVersao” através do console do NuGet como já demonstrado antes, e depois atualize o banco informando a “SegundaVersao”. Ao conferir o banco você verá que foi adicionada a chave estrangeira a tabela "opcaos" sem deletar o banco, apenas realizando as modificações necessárias.


Neste artigo pudemos aprender como fazer migrações/atualizações no banco de dados de maneira rápida, simples e 100% ao controle do desenvolvedor quando se utiliza o Entity Framework Code First, a partir deste exemplo você será capaz de partir para outros estudos.


Para saber mais:

Aprofunde seus conhecimentos sobre ADO.NET

Blog ADO.NET

Blog da Julie Lerman's

Download do Nuget

Exibições: 3304

Comentar

Você precisa ser um membro de DevBrasil para adicionar comentários!

Entrar em DevBrasil

Comentário de Leandro Carvalho Guimarães em 23 fevereiro 2012 às 15:05

Julio Cesar Rodrigues da Silva pelo q eu acompanho parece que continua. Por outro lado o EF5 trará uma melhora de performance ficando mais próximo da performance do ADO puro. Pelo q eu entendi é necessário essa perca de desempenho na primeira vez. Creio que não exista nenhuma perspectiva de melhoria quando a isso para os próximos dias.

Comentário de Julio Cesar Rodrigues da Silva em 2 fevereiro 2012 às 13:51

Alguma novidade referente a lentidão na utilização do code first??

na primeira vez quem que o SaveChanges é chamado

Comentário de Leandro Rodrigues em 23 janeiro 2012 às 14:20

Irá trabalhar com coleções? Então não pense em minuto utilize ADO.NET EntityFramework!!! =D

Comentário de Leandro Rodrigues em 23 janeiro 2012 às 14:17

 

Curti o artigo, escreveu bem, Linq é uma mão na roda, embora muita gente ainda confuda algumas coisas, escuto pessoas falando que Linq é mais rápido que ADO.NET, não é mais rápido não embora a diferença seja nos milesegundos não é, única coisa que o Linq ganha do ADO.NET em performance é quando o ADO.NET é utilizado com DataSet. 

 

Mas em fim, desde que criaram o linq em 2005 muita coisa mudou =D 

Parabéns 

Comentário de Leandro Carvalho Guimarães em 15 janeiro 2012 às 20:06

Alexsandro,

você informa o nome da connectionstring na chamada do construtor pai do construtor do seu contexto.

Exemplo:

public IntranetContext() : base("IntranetContext")

<add name="IntranetContext"
connectionString="Data Source=web\intranet;Initial Catalog=intranet;MultipleActiveResultSets=True;User ID=sa;Password=123456"
providerName="System.Data.SqlClient"/>

Comentário de Alexsandro Pereira em 15 janeiro 2012 às 13:57

Estou com problema para especificar qual é minha ConnectionString como pedir pra executar comandos como Add-Migration ou Update-Database. Como Eu devo fazer? Ele pede pra implementar a Interface IDbContextFactory<MeuContexto> mas onde eu devo implementa-la? Ja testei na minha classe de contexto e na classe de Configuração do Migration. Alguma ideia?

Comentário de Geovani Gustavo Sajorato Succi em 14 janeiro 2012 às 18:05

Muito bom. Trabalho com EF desde a versão 4. Também acredito que será o carro chefe logo em breve. Abraços dev's.

Comentário de Leandro Carvalho Guimarães em 13 janeiro 2012 às 13:31

Falta muita coisa para o Entity ser o carro chefe, fico lendo a página de sugestões dos usuários e realmente tem muito oq fazer ainda.

Até problema de integração com recursos do próprio framework está tendo. Mas eu acredito que será o principal framework ORM da Microsoft.

O problema dele está sendo o mesmo do Windows Phone: Atraso!

Comentário de Yan de Lima Justino em 12 janeiro 2012 às 10:04

Cara, bom post. Estou utilizando estas novas funcionalidades do entity. Espero que a versão final do migration saia logo. rsrssrs

Comentário de Leandro Carvalho Guimarães em 9 janeiro 2012 às 9:23

Muito bem lembrado @Marcelo Paiva, ainda é beta. Ver Alpha 3

© 2019   Criado por Ramon Durães.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço