Como utilizar Migrations em aplicações desenvolvidas com Entity Framework Code First
Esse artigo fala sobre versionamento de base de dados usando Entity Framework Migrations durante o desenvolvimento de um projeto, tanto para projetos novos quanto para projetos já existentes.
Em ambiente de desenvolvimento, principalmente com um software sendo desenvolvido de forma incremental, a base de dados muda muitas vezes antes de chegar a seu estado final. Nesses momentos a utilização de migrations é fundamental. O Entity Framework Migrations fornece uma forma prática para lidar com essas mudanças.
Temos duas principais frentes no que diz respeito à ordem e gestão dos processos durante o desenvolvimento de um software, a primeira e mais utilizada é o modelo waterfall, ou em cascata, onde o software passa por diversas etapas até sua entrega, e em teoria, o sistema possui todos os seus requisitos levantados no início e o projeto de software possui uma arquitetura, design, vários diagramas e estrutura da base de dados feita logo no início.
A outra é a frente ágil onde o desenvolvimento de software é incremental, as necessidades são separadas em pequenas partes e o sistema não é imutável ocorrendo entregas periódicas com novas partes do sistema.
Em qual desses modelos de trabalho você imagina que os dados necessários para a aplicação não precisaram sofrer mudanças? Como deve imaginar, em um modelo ágil, como há releases incrementais, os dados necessários podem mudar muitas vezes.
Por exemplo, para o sistema de vendas eram guardados os dados de produtos, ordens de pedido, vendedores, etc., e na próxima entrega é necessário o sistema de cubagem, agora os produtos precisam guardar dados de suas dimensões físicas, algo não pensado na entrega anterior. Logo, o banco de dados precisa de alterações nas tabelas referentes aos produtos.
Mas engana-se se você acredita que não haverá mudanças na hora de programar um sistema que usa o modelo waterfall. Mesmo que o sistema tenha sido todo desenhado previamente, algumas coisas só são percebidas na hora de programar (um dos muitos motivos para se preferir o modelo ágil), por exemplo: durante o desenvolvimento do sistema de vendas já tinha sido definido que teria um sistema de cubagem, logo, já tinha na tabela de produtos as colunas para as dimensões físicas dos produtos, porém não havia uma coluna para indicar se o produto era frágil, assim precisando ser embalado com mais plástico bolha, alterando o cálculo de quantos produtos cabem numa caixa. Nesse caso é preciso alterar a tabela adicionando mais um campo.
Chegamos à conclusão que muito provavelmente enquanto você ou sua equipe estiverem programando haverá mudanças que podem refletir em alterações na base de dados.
Mas não precisa pensar somente em requisitos que foram alterados, novos releases ou grandes mudanças, pense em algo simples: imagine que você é um programador dessa equipe, a equipe que fará o sistema de vendas.
Você começa com uma classe chamada Produto bem simples, porém o seu superior gostaria de mostrar para o cliente uma tela de cadastro de produtos, então você faz o suficiente do sistema para o cadastro de produtos.
Mais tarde irá adicionar o cadastro de clientes e terá que rodar um script para alterar a base de dados e adicionar a tabela referente a clientes. E assim, durante a programação, você vai rodando continuamente scripts para alterar a base de dados.
Agora você vê que mudanças na base podem ocorrer a todo o momento. E se enquanto você está fazendo o sistema de cubagem, recebe uma notificação de que essa parte do sistema estará fora do produto final, ou seja, somente a venda será feita, a parte de cubagem será cancelada.
Você precisa criar um script que apague as tabelas referentes à cubagem, como a tabela de caixas, por exemplo. Mas alguma sujeira pode ficar, por exemplo, não é mais necessária a coluna que indica se o produto é frágil, mas você esqueceu de retirar ao voltar o banco de dados como era antes.
Agora o sistema possui tabelas com colunas lixo, colunas que não serão usadas e não foram retiradas ao retornar o que o sistema era sem a parte de cubagem.
Claro que esse exemplo se aplica somente a base de dados relacionais que usam tabelas. Campos sujos ainda podem existir em base de dados NoSQL (BOX 1), porém essas base de dados não fazem parte do escopo desse artigo.
BOX 1. Bancos NoSQL
Bancos de dados NoSQL (acrônimo de Not Only SQL) significam que não são somente SQL, ou seja, vão além do conceito de SQL. Isso não significa que não possuem tabelas, por exemplo, o BigTa ...
