Está usando classes parciais para suportar várias versões de entidades de dados para cenários de entrega contínua uma idéia ruim?

5

Quando você deseja ter entrega contínua, todos os esquemas de dados necessários devem ser compatíveis com várias versões do aplicativo ao mesmo tempo (já que você pode ter várias versões implantadas quando novas versões estiverem sendo lançadas)

No meu caso específico, tenho entidades armazenadas no armazenamento de tabelas do Azure. Quando estou fazendo alterações em minhas entidades, geralmente estou tendo que adicionar propriedades (como removê-las ou renomeá-las é uma má ideia, já que versões antigas do aplicativo provavelmente serão interrompidas), mas uma vez que uma nova versão é completamente implantada, não preciso as versões antigas já que todos os servidores estão usando a nova versão, o que significa que na próxima implementação posso remover algumas das propriedades antigas.

Gostaria de saber se esse problema pode ser resolvido mais facilmente com classes parciais para cada versão da entidade. Isso garante que uma versão seja sempre acumulativa para uma versão anterior (ou seja, nunca removerá nada nem alterará nada), mas permitirá a delegação a uma propriedade existente se algo precisar ser renomeado.

Uma vez que uma versão tenha sido completamente implementada e a versão antiga nunca seja necessária, as classes parciais poderão ser consolidadas em uma única classe novamente (e quaisquer propriedades desnecessárias serão removidas). Se você sabe que terá apenas algumas versões 'ao vivo' a qualquer momento, talvez possa usar uma versão 'atual' e uma versão 'vNext' explicitamente.

Eu não tentei isso como uma solução ainda, mas imaginei se alguém já tentou uma abordagem como essa e tem algum feedback, ou se alguém tem pensamentos sobre se isso é uma ideia boa ou ruim?

    
por Sam Holder 24.05.2014 / 15:01
fonte

2 respostas

1

Classes parciais são apenas um meio de dividir uma classe em vários arquivos. É particularmente útil quando partes de uma classe podem ser geradas, mas você também quer código personalizado. Não vejo como isso ajuda você a selecionar quais propriedades são obsoletas para uma nova versão ou não.

Sugiro atribuir propriedades obsoletas com [Obsolete("since version ...")] para rastrear quais propriedades você pode remover mais tarde.

Você pode ter uso para separar APIs antigas e novas com entidades diferentes, e essas podem se beneficiar da herança, para especificar claramente quais propriedades nem existiam na api mais antigos.

    
por 24.04.2016 / 19:58
fonte
0

Eu não gosto da ideia de classes parciais, sua solução se tornará um túmulo.

Se você estiver usando SQL, poderá usar o SSDT (Ferramentas de dados do SQL Server) e terá a capacidade de executar o pré-script ou pós-script durante a implantação, ler a versão atual do servidor e depender desta versão alterar, atualizar, excluir ... E, em seguida, atualize a versão após o script ser concluído com êxito.

    
por 01.04.2016 / 10:08
fonte