Porta do EF6 para o EF Core – Banco de dados como Fonte da Verdade

Se você estiver usando o banco de dados como fonte da verdade, a atualização envolverá principalmente o endereçamento de alterações na forma de entidades geradas. As etapas da migração incluem:

1. Escolha um ponto no tempo para modelar o banco de dados.
2. Verifique se os projetos EF6 estão atualizados e sincronizados com o banco de dados.
3. Crie o projeto EF Core.
4. Use as ferramentas de scaffolding para fazer a engenharia reversa do seu banco de dados para o código.
5. Valide se as classes geradas pelo EF Core são compatíveis com seu código.
6. Para exceções, modifique as classes geradas e atualize a configuração do modelo ou adapte seu código ao modelo.

Observe que, embora o EF Core atualmente faça scaffolding de tudo o que é necessário para gerar com êxito uma cópia do banco de dados, grande parte do código não é necessária para a abordagem que prioriza o banco de dados. Uma correção para isso está registrada no Problema nº 10890. Entre os itens que é possível ignorar com segurança por não serem necessários estão: sequências, nomes de restrições, índices não exclusivos e filtros de índices.

Lidar com as alterações de esquema

Quando seu banco de dados é a fonte da verdade, o EF Core extrai informações de esquema do banco de dados em vez de enviá-las por meio de migrações. O fluxo de trabalho típico é executar novamente a etapa de engenharia reversa sempre que o esquema do banco de dados for alterado. Um conjunto de testes abrangente é valioso para essa abordagem porque você pode automatizar o processo de scaffolding e verificar as alterações executando os testes.

Dicas para lidar com diferenças de modelo

Por vários motivos, talvez você queira que seu modelo de domínio C# tenha um formato diferente daquele gerado na engenharia reversa. Em muitos casos, isso significa atualizar manualmente o código que é gerado automaticamente após cada alteração de esquema. Uma maneira de evitar esforço extra quando o código for regenerado é usar classes parciais para seu DbContext e entidades relacionadas. Em seguida, você pode manter o código relacionado à lógica de negócios e às propriedades não rastreadas no banco de dados em um conjunto separado de arquivos de classe que não serão substituídos.

Se o seu modelo for significativamente diferente do modelo gerado, mas não for alterado com frequência, uma opção a ser considerada é o uso do padrão de repositório como adaptador. O repositório pode consumir as classes geradas pelo EF Core e publicar as classes personalizadas usadas. Isso pode reduzir o impacto das alterações, isolando-as no código do repositório, em vez de ter que executar uma refatoração em todo o aplicativo sempre que o esquema for alterado.

Talvez você queira considerar um fluxo de trabalho alternativo e seguir etapas semelhantes à abordagem híbrida. Em vez de gerar um novo conjunto de classes a cada vez, indique tabelas específicas para gerar apenas novas classes. Mantenha as classes existentes "como estão" e adicione ou remova diretamente as propriedades que foram alteradas. Em seguida, atualize a configuração do modelo para resolver as alterações na forma como o banco de dados mapeia as classes existentes.

Personalizar a geração de código

Atualmente, o EF Core 6 não oferece suporte à personalização do código gerado. Há soluções de terceiros, como o EF Core Power Tools, que estão disponíveis. Para obter uma lista das ferramentas e extensões da comunidade em destaque, confira: Ferramentas e Extensões do EF Core.

Por fim, examine a lista detalhada de diferenças entre o EF6 e o EF Core para resolver os problemas restantes com a portabilidade.