Entity Framework Migrations

Entity Framework Migrations

No decorrer do desenvolvimento de um projeto mudanças podem ocorrer no planejamento, no código e no banco. Mudanças no código são simples de se contornar pois possuímos ferramentas para controle de versão do código, possibilitando voltar atrás, juntar versões e controlar a vida do nosso código. Porém o controle de versões do banco de dados relacional (SGBDR) é um pouco mais complexo. 

Nesse artigo veremos como manter versões com o Entity Framework Migrations.


Introdução

Em algumas empresas o controle de versões ficar em procedures, em que a cada versão era criada uma proc nova que iria alterar ou recriar a base e alimentar com dados para teste. Porém eram procs criadas manualmente.

Alguns frameworks de ORM vinham com um controle de versão da base de dados, como exemplo o Hibernate no java, o Active Record no ruby, o Doctrine no php, o projeto open source Migrations.net baseado no Active Record e vários outros. Mas o Entity Framework, framework ORM da Microsoft, open source, não possuía um controle de versão desde o seu inicio.

O suporte a migrations veio somente na versão 4.3.1 do Entity Framewrok, anteriormente tínhamos apenas 3 escolhas de estratégias para a criação de data bases: CreateDatabaseIfNotExists que somente cria a base se ela não existir, DropCreateDatabaseAlways que sempre apaga e recria o base de dados,  DropCreateDatabaseIfModelChanges que apaga e recria a base somente se o modelo foi alterado sendo essa a opção mais próxima do que precisávamos  mas ainda não era perfeita pois acabávamos perdendo os dados antigos e caso precisássemos voltar a versão não era possível.

Com o Code First Migrations podemos ter versões da base de dados, voltar versões e manter um histórico. O Migrations vigia suas classes POCO e cria métodos de update e downgrade com o código necessário para aplicar as mudanças. Algo interessante é ressaltar que podemos alterar com lambda expressions ou com SQL puro as mudanças que o Migrations vai fazer, caso quisermos.

Mas para utilizar o Migrations você precisa habilita-lo. Na Package Manager Console use o comando:

Enable-Migrations

Mesmo que você não tenha habilitado na criação da sua base de dados, se criada pelo Code First, vai ser criada uma tabela do sistema com a migration inicial. Ao habilitar o Migrations vai ser criada uma pasta para os arquivos de código das migrations. Depois você tem dois caminhos: Migrations normal e automatic Migrations.

Migrations normal

O caminho normal do Migrations consiste em por linha de comando você criar uma migration dando um nome para ela e depois rodando o comando de update. Sem fazer isso vai ser gerada uma exception a cada vez que seu modelo mudar. Exemplo de criação de migration e rodar o update:
Add-Migration NomeDaMigration
Update-database

Ao adicionar uma Migration vai ser adicionado um arquivo com o código da migration na pasta migrations do seu projeto, o nome é um timestamp seguido do nome que você deu a sua migration, como mostra a próxima imagem. É por esse timestamp que o migrations sabe a ordem delas.



Nesse arquivo você vai encontrar uma partial class com os métodos de Up e Down, o Up será rodado no update da base de dados para aquela migration e o Down quando você estiver numa versão posterior e quiser voltar até ela. Você pode sobre escrever esses métodos e mudar a sua lógica de up e down.

 

Como você pode ver é usado por default lambda expressions, mas você pode incluir código SQL se quiser.
Você também pode ver o código SQL gerado usando o parâmetro -Verbose na hora de rodar o update. E para não rodar o update mas só ver o Sql que seria gerado (caso queira roda-lo manualmente) use o parametro -script.

Voltar uma migration

Caso esteja numa versão posterior e queira voltar uma versão é só no ao rodar o comando update dizer o nome completo da migration com o parâmetro TargetMigration, incluindo o timestamp, como no exemplo:

Update-Database -TargetMigration:"201210301049442_second2"


Automatic Migrations

Ao usar o caminho Automatic Migrations você não precisa criar uma migration a cada mudança no modelo, somente rodar o comando update. Apesar de parecer mais rápido tem os contras: não possui um scaffolding para a geração de métodos de update e downgrade, afinal, você não cria pontos intermediários de versão.

Para habilitar o Automatic Migrations você tem dois caminhos, rodando um comando na Package Manager Console:

Enable-Migrations -EnableAutomaticMigrations

Ou habilitando via código na Configuration geral das suas Migrations (classe que é criada dentro da pasta Migrations):

Migration:AutomaticMigrationsEnabled = true;

Bem, esse é o modo de usar Entity Framework Migrations. O Entity Framework 6 já está em alpha, em breve poderemos ter mais novidades no Migrations.

Post Original: Entity Framewrok Migrations
Classificar por: Data da Publicação | Mais Recente | Mais Úteis
Comentários
  • Excelente artigo Pri !!!

  • Pergunta que não quer calar, levo o source com o squema do entity pra outra máquina/servidor, com outro BD e outro Nome, como exporto / atualizo tudo pra evitar problemas e funcionar direito?

  • Parabéns, Priscila!

  • Parabéns Priscila, continue com ótimo trabalho.

  • Guilherme MA: somente hoje vi seu comentário :p

    Na verdade não entendi direito. Do jeito que você fala parece usar somente SQL CE.

    EF é um ORM e não possui nativamente uma ferramenta de exportação de dados

Página 1 de 1 (5 itens)