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

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

1. Escolha um ponto no tempo para modelar o banco de dados.
2. Verifique se os projetos EF6 estão atualizados e em sincronia com o banco de dados.
3. Crie o projeto do EF Core.
4. Use as ferramentas de suporte para fazer engenharia reversa do banco de dados para gerar 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 gere a estrutura necessária para gerar com êxito uma cópia do banco de dados, grande parte do código não é necessário para a abordagem "database-first". Uma correção para isso é acompanhada em Problema nº 10890. As coisas que você pode ignorar com segurança, conforme não necessário, incluem: sequências, nomes de restrição, índices não exclusivos e filtros de índice.

Manipulando alterações de esquema

Quando o banco de dados é a fonte da verdade, o EF Core extrai as informações do esquema do banco de dados, em vez de aplicá-las por meio de migrações. O fluxo de trabalho típico é executar novamente a etapa de engenharia reversa sempre que o esquema de banco de dados for alterado. Um conjunto de testes abrangente é valioso para essa abordagem porque você pode automatizar o processo de estruturação 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# seja moldado de forma diferente daquela gerada na engenharia reversa. Em muitos casos, isso significa atualizar manualmente o código gerado automaticamente após cada alteração de esquema. Uma maneira de evitar esforço extra quando o código é 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 monitoradas no banco de dados em um conjunto separado de arquivos de classe que não serão sobrescritos.

Se o modelo for significativamente diferente do gerado, mas não mudar com frequência, uma opção a ser considerada é o uso do padrão de repositório como um adaptador. O repositório pode consumir as classes geradas pelo EF Core e publicar as classes personalizadas que você usa. 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, você indica tabelas específicas para gerar apenas novas classes. Você mantém as classes existentes "como estão" e adiciona ou remove diretamente as propriedades que foram alteradas. Em seguida, você atualiza a configuração do modelo para resolver quaisquer alterações na forma como o banco de dados é mapeado para suas classes existentes.

Personalizar a geração de código

Atualmente, o EF Core 6 não dá 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 de ferramentas e extensões da comunidade em destaque, consulte: 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 quaisquer problemas restantes com a portabilidade.