O código da estrutura da entidade primeiro é um pouco sem sentido / inútil na produção e o que é uma boa estratégia da EF para a produção?


29

Tenho programado recentemente com o Entity Framework 4.1 Code First e estou adorando o desenvolvimento, mas com apenas um plano final e uma lista de recursos que muda rapidamente, estou constantemente modificando o Class / Database para atender às necessidades dos aplicativos.

No desenvolvimento, não há dados ativos e eu posso facilmente excluir todo o banco de dados, para que seja recriado com o novo esquema, no entanto, obviamente, quando ativos - isso é muito ruim!

As únicas soluções que posso ver são descartar a tabela de metadados e manter manualmente o banco de dados em sincronia ou basicamente descartar e reenviar.

Pessoalmente, prefiro o primeiro método, pois acho que será muito mais fácil adicionar uma coluna / tabela do que recriar e migrar dados, mas, a menos que eu tenha perdido alguma coisa, isso será completamente diferente do Code First.

Portanto, a questão é: o Code First é apenas sobre o desenvolvimento inicial e qual é uma boa estratégia para gerenciar o EF em um ambiente de produção?


Foram significado para pedir isso por alguns dias, não tinha certeza se era melhor aqui ou no Stack Overflow ...
wilhil

Respostas:


15

Minha opinião é que a criação automática de banco de dados do code first é apenas para desenvolvimento. Respondi a perguntas semelhantes no Stack Overflow, onde descrevi como atualizar o banco de dados e por que a funcionalidade automática é ruim na produção:

Atualizar o banco de dados é tarefa semi-manual. Não deve haver mágica automática não testada por trás - além disso, o EF 4.1 atualmente não possui essa mágica disponível (há apenas uma apresentação sobre os recursos que a equipe do ADO.NET está trabalhando).

Você também pode verificar esta pergunta para entender melhor como os sites são atualizados.


Olá de novo! -Você é rápido nas perguntas da EF! :) ... Não sei onde eu estaria sem você!
Wilhil 13/05/11

Alguns meses depois, e meu programa está bastante concluído ... Estou marcando isso como resposta, mas fiquei pensando se alguma coisa mudou / há algum recurso que possa ajudar?
wilhil

2
A primeira prévia pública de "Migrações" foi lançada. blogs.msdn.com/b/adonet/archive/2011/07/27/…
Ladislav Mrnka

Obrigado, olhando para isso agora! Adorei desenvolver com o Code First, mas estou muito nervoso / preocupado em mudar mais tarde!
wilhil

Como você lida com o caso em que StoredProcs ou Views são criados diretamente no banco de dados para outros fins, por exemplo, relatórios que não são usados ​​pelo aplicativo. Precisamos saber primeiro quais SPs são afetados por uma alteração de esquema no código.
softveda

5

Manter scripts de atualização .

No próprio banco de dados, mantenha uma tabela na qual um registro é mantido com a versão do esquema.

Quando você inicia o aplicativo, ele detecta a versão com a versão que deveria ser usada pelos binários. Se for diferente, execute (ou peça ao usuário) os scripts de atualização.

Não se esqueça de fazer backup do banco de dados primeiro.


Próxima etapa: você está demitido;) As atualizações do banco de dados não devem aparecer automaticamente sem um backup primeiro - e possivelmente em tempo de inatividade, não quando UM USUÁRIO executa uma versão mais recente. Sua abordagem é perfeita - para encerrar implantações maiores com muitos erros.
TomTom

@ TomTom: isso depende. Estamos executando um aplicativo de banco de dados na perfeição por vários anos, o que faz exatamente isso: o esquema automático é alterado para uma nova versão, feita pelo aplicativo quando ele detecta uma versão muito antiga. Os backups são feitos diariamente também, e mantemos todas as alterações de esquema compatíveis com versões anteriores (apenas adicionando campos e tabelas, nunca excluindo nenhuma). Concordo que as medidas que você mencionou são importantes quando as alterações não são compatíveis com versões anteriores e você não pode garantir que todos os aplicativos clientes sejam atualizados simultaneamente (por exemplo, para DBs de grandes empresas).
Doc Brown

No topo, se as alterações não forem triviais. Tente alterar um campo em uma tabela de 2 TB (e sim, eu lido com isso - e nem sequer é um data warehoue). Você se colocou em um cenário em que está acumulando dívidas técnicas porque pode apenas adicionar campos, nunca limpar.
TomTom

2

De alguma forma, a questão é falha, pois ela faz conexões entre o modelo de programação e o ambiente de tempo de execução onde não há.

O código primeiro é principalmente um driver de velocidade de desenvolvimento e não está realmente conectado ao sistema de tempo de execução.

Na produção, você terá adequadamente uma configuração que nega ao tempo de execução a possibilidade de excluir / atualizar o modelo db.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.