Como devo gerenciar diferentes formatos incompatíveis de documentos baseados em XML

Question

Eu tenho uma aplicação que guarda documentos (acho que documentos do Word) em um formato baseado em XML - aulas Atualmente C # gerados a partir de arquivos XSD são usados ??para ler / escrever o formato de documento e tudo estava bem até recentemente, quando eu tive que fazer uma mudança o formato do documento. Minha preocupação é com compatibilidade com versões anteriores como as futuras versões do meu aplicativo necessidade para ser capaz de ler documentos salvos por todas as versões anteriores e, idealmente, eu também quero versões mais antigas do meu aplicativo para ser capaz de graciosamente lidar com a leitura de documentos salvos por futuras versões do meu aplicativo.

Por exemplo, supondo que eu alterar o esquema do meu documento para adicionar um (opcional) elemento em algum lugar extra, versões em seguida, mais velhos do meu aplicativo irá simplesmente ignorar o elemnt extra e não haverá problemas:

<doc>
    <!-- Existing document -->
    <myElement>Hello World!</myElement>
</doc>

No entanto, se uma alteração de quebra é feita (um atributo é transformado em um elemento por exemplo, ou uma coleção de elementos), em seguida, versões anteriores do meu aplicativo deve ignorar este elemento se ele é opcional, ou informar o usuário que eles está tentando ler um documento salvo com uma versão mais recente do meu aplicativo de outra forma. Além disso, este é actualmente causando-me dores de cabeça como todas as versões futuras da minha necessidade aplicativo de código totalmente separado é necessário para ler os dois documentos diferentes.

Um exemplo de tal mudança um seria o seguinte xml:

<doc>
    <!-- Existing document -->
    <someElement contents="12" />
</doc>

Mudar para:

<doc>
    <!-- Existing document -->
    <someElement>
        <contents>12</contents>
        <contents>13</contents>
    </someElement>
</doc>

Para evitar dores de cabeça de apoio no futuro eu queria vir para cima com uma estratégia decente para lidar com as mudanças que eu poderia fazer no futuro, de modo que as versões do meu aplicativo que eu solte agora vão ser capazes de lidar com estes mudanças no futuro:

• Caso o "número da versão" do documento ser armazenado no próprio documento, e em caso afirmativo qual a estratégia de versão deve ser usado? Caso a versão do documento corresponder à versão de montagem .exe, ou deve uma estratégia mais complexa ser utilizado (por exemplo grande revisão mudou indicam alterações significativas, wheras incrementos de revisão menores indicam mudanças não quebrar - por exemplo, elementos extra opcional)
• O método que deverá utilizar para ler o documento em si e como faço para evitar a replicação enormes quantidades de código para diferentes versões de documentos?
  • Embora XPath é, obviamente, mais flexível, é muito mais trabalho para implementar do que simplesmente gerando aulas com XSD.
  • Por outro lado, se DOM de análise é usado, em seguida, uma nova cópia do xsd documento seria necessário no controle de origem para cada alteração de quebra, causando problemas se correções precisar ser aplicada a esquemas mais antigos (versões antigas do aplicativo são ainda suportado).

Além disso, tenho trabalhado tudo isso muito loosly no pressuposto de que todas as mudanças que eu faço pode ser dividida em estas duas categorias de "mudanças Beaking" e "alterações não separáveis", mas eu não estou totalmente convencido de que este é uma suposição segura para fazer.

Note que eu uso o termo "documento" muito vagamente - o conteúdo não se assemelhar a um documento em tudo

Obrigado por qualquer conselho que você pode me oferecer.

Answer 1

Você definitivamente precisa de um número de versão no arquivo XML, e gostaria de sugerir não amarrando-o para a versão da aplicação porque é realmente uma entidade separada. Você pode através de duas ou três versões de seu aplicativo sem nunca mudar o formato XML ou você pode acabar mudando o formato várias vezes durante o desenvolvimento de um único lançamento.

Se você quiser versões mais antigas do aplicativo para ser capaz de ler versões mais recentes do arquivo XML, então você pode nunca, nunca remover elementos ou alterar seus nomes. Você sempre pode adicionar elementos eo código antigo será feliz ignorá-los (uma das características interessantes de XML), mas se você removê-los, em seguida, o código antigo não será capaz de funcionar.

Como Ismael disse, XSLT é uma boa maneira de converter o formato XML a partir de uma versão para outra, para que você não acabar com toda uma pilha de análise de rotinas em seu código-fonte.

Answer 2

XSLT é uma escolha óbvia aqui. Dado que você pode identificar a versão do seu documento, para cada versão do seu esquema, creat um XSLT que transforma a versão anterior para a nova versão.

Você pode aplicar as transformações em seqüência até chegar à versão atual. Assim você está sempre apenas editar a versão mais recente do documento. Claro, você não será capaz de salvar para o formato antigo e pode quebrar o documento para versões mais antigas, mas isso é típico de muitas aplicações. Se for absolutamente necessário para salvar a versão antiga, basta criar uma transformação que vai por outro caminho.

Como @Andy diz, utilize o maior número de compilação do seu aplicativo.

Answer 3

Você pode adicionar um atributo para a versão elemento raiz especificando?

versões Dessa forma, mais velhos não vai ser quebrado, e novas versões do seu software vai ver o atributo e mudança para um método de carregamento diferente de forma adequada.

Versão numeração em si iria depender da sua frequência de liberação. Eu pessoalmente ir com o maior número de compilação de seu software, a menos que você prever o formato mudar mais frequentemente do que isso.

Editar : só notei o pouco sobre a duplicação de código:

Por que eu iria usar o padrão de fábrica, algo como isto:

LoadDocument
DoNonVersionDependingLoading
VersionSpecificLoaderFactory(VersionNumber)