Pergunta

Eu faço um monte de sistemas de programação, onde meus aplicativos não têm nenhuma chance de ser usado para se comunicar através da web ou visualizados através de um browser. Mas, tem havido alguma pressão pela administração para XML uso. Por exemplo, se eu quiser manter um registro do tempo que eu poderia usar um arquivo de texto como este:

tempo data de comando do projeto
em 2008/09/23 08:00:00 Proj1
mudança 2008/09/23 09:00:00 Proj2
fora 2008/09/23 12:00:00 Proj2
em 2008/09/23 01:00:00 PROJ3
fora 2008/09/23 05:00:00 PROJ3

O XML seria algo parecido com isto:

<timelog> <timecommand cmd=in date=2008/09/23 time=8:00:00 proj=PROJ1/>
...
<timecommand cmd=out date=2008/09/23 time=5:00:00 proj=PROJ3/>
</timelog>

Algumas das vantagens iniciais da versão de texto que eu vejo é que é facilmente legível e parsable com regex. Quais são as vantagens de se utilizar XML neste caso?

Foi útil?

Solução

Não há absolutamente nada de errado com o uso de dados baseados em texto de formatação. Ele tem sido o padrão de fato durante décadas. sistemas financeiros enormes mainframes grandes ainda usá-lo hoje. Os benefícios são que é trivial para produzir, trivial para consumir e incrivelmente leve. E como sobre arquivos de log? Sabe qualquer plataforma de produção que não gerar seu arquivo de log em um formato de texto delimitado (web, app, servidor db)?

A desvantagem de arquivos de texto simples é que, se as alterações no formato, então você tem que modificar tanto o produtor e as extremidades de consumo não-trivial para ser capaz de suportar a mudança de formato. Claro, se é apenas um ser humano consome o resultado, então você só tem que mudar o produtor.

A beleza de XML é que a análise dos dados é independente não só os dados, mas o formato dos dados. Logicamente você passá-lo tanto os dados eo formato de dados, e presto! Tudo funciona. Não é exatamente assim tão simples, mas essa é a premissa. Você pode alterar o formato dos dados, e seus produtores e consumidores só tem que mudar trivialmente (se em tudo).

O feio de XML é que ele pode ser um cão grande desempenho SOAP (alguém?) E peso muito pesado. Você definitivamente pagar um preço por sua extensibilidade. Há casos em que é absolutamente a solução técnica otimizada para um determinado domínio do problema, e há outros casos em que não é.

Então, se é um simples log que um ser humano vai ler, mantê-lo arquivo simples. Se é um aplicativo simples comunicação com outro único aplicativo e as comunicações não vai mudar drasticamente ao longo do tempo, arquivo simples é definitivamente mais rápido e mais leve de implementar, mas XML não é uma má escolha. Se vários aplicativos precisam consumir os dados que você está oferecendo ou se o volume de mudança comunicação vai ser alto, em seguida, ir com XML. A manutenção da interface será mais facilmente mantida ao longo do tempo se você fizer.

Outras dicas

Um par de benefícios vêm à mente:

  • É mais fácil de analisar em outras aplicações
  • É mais fácil entender o que o documento mantém em um relance
  • Torna mais fácil para extrair dados em um painel gerencial
  • Faz o feliz gestão com pouca dor para você

As desvantagens, como eu vê-los:

  • Meios alterar o código existente, provavelmente desnecessariamente
  • degradação do desempenho leve possível, dependendo de como você construir os documentos em relação à forma como você gerar os documentos atuais
  • É de XML por causa do XML, que é effin' estúpido

E, para fechar, uma citação pretendido como ironia: XML é como a violência. Se ele não está resolvendo seus problemas, você não está usando o suficiente

principal característica do XML em um caso como este é que XML pode ser validada e controlada. Na versão de texto, como você seria capaz de verificar programaticamente que o arquivo está formatado corretamente? XML é projetado para criar estruturado, documentos válidos, eo benefício resultante é um formato é rigidamente controlado e confiável estruturado. Manutenção de código que lê a partir nós XML também vai ser muito mais fácil e mais logicamente colocado para fora do que manter uma série de expressões regulares para a leitura de arquivos de texto.

Se você usar XML, em seguida, em alguns aspectos, os dados seriam mais "portátil". Você teria têm essencialmente analisadores de seus dados disponíveis na maioria dos ambientes, assim que escrever uma ferramenta para analisar os dados pode ser mais fácil. Além disso, se ele está em XML, então você pode escrever um XSLT para transformá-lo em vários outros formatos, tornando-o mais fácil de ler.

Dito isto, se você passar a usar XML, mesmo um formato simples como o exemplo que você deu, seus arquivos de log vão se tornar muito maior.

Existem alguns outros do que XML que você pode usar opções. Ângulo suporte de imposto de Jeff blog fala post sobre isso um pouco.

Realmente, o que você deve fazer é descobrir como esses logs estão indo para ser usado, e então determinar qual o formato tornaria esses usos mais fácil de implementar.

É facilmente parsable usando regex e XML e XSL.

A verdade seja dita, não há realmente uma "vantagem" para o uso de XML a menos que você está enviando os dados para outro sistema.

XML é uma meta-formato, o que significa que torna mais fácil para definir um formato para seus dados. Isto torna mais fácil para vários programas, inclusive por diferentes empresas, para ler e gravar dados no mesmo formato. É especialmente adequado como uma descrição de dados complexos, hierárquica.

No exemplo a delinear acima, os olhares de dados a ser isolado registros em um formato fixo, sem nenhuma estrutura ou hierarquia - caso em que não vejo qualquer vantagem em usar XML. No entanto, o exemplo pode ser pouco representativa -. Seus outros arquivos podem conter dados mais estruturados

É um arquivo de log em curso?

Como é que você nunca vai escrever o para criar um documento válido? Ou você vai lê-lo em, adicionar a nova entrada, e escrevê-lo de cada vez?

Os arquivos de log são candidatos perfeitos para linhas de texto simples bem estruturadas que você simplesmente anexar a.

I maioria dos casos (nem sempre), XML torna mais fácil entender os dados, porque de repente você tem que os dados de meta em torno de seu ativo descrevendo o que está lá na frente de você (legível).

XML também é muito acessível. O que quero dizer com isso é que - desde que você mencionou isso - você não quer usar expressões regulares em XML. Existem ferramentas como XPATH (XML Path Language) que fazem consultando divertido XML. Não há necessidade de sacar algo que ninguém mais pode ler quando você pode travers facilmente através de XML usando algo como XPath.

Há casos em XML faz o contrário (em termos de legibilidade) e às vezes XML também é alto. Não é sempre a melhor escolha quando você troca de dados entre sistemas (por exemplo, dar uma olhada em algo realmente leve como JSON ). E esse tipo de troca não precisa estar na web também.

Enquanto usando XML para arquivos de dados significaria que seus dados podem ser auto descrevendo e talvez melhor organizado, o resultado final é, muitas vezes os arquivos de dados que são muito maiores do que antes.

Pergunte a si mesmo, o que são os arquivos usados ??para? São eles que ser mudado? Se assim for, quem está pagando e quem tem um orçamento para isso?

Eu amo XML em alguns casos, e em outros eu odeio isso!

No caso da programação batch sistemas como você está falando, uma das principais características xml é que ele é suportado em quase toda parte. Então você escrever um programa para lidar com alguns dados hoje usando XML, e em 10 anos, quando você precisa de revisar esse programa e quiser usar uma plataforma completamente diferente, você dados XML ainda será bem suportado.

Se o seu desenvolvimento em .NET (especialmente .NET 3.5 com LINQ to XML) você vai escrever menos código para ler / escrever o XML que se você usou apenas um arquivo de texto simples. Além disso, XML apenas torna mais fácil para qualquer pessoa para baixo da linha para ler o arquivo e saber exatamente o que está nele e para que serve. E, não se preocupe com o XML ocupando um espaço de pouco mais rígido, espaço em disco é barato.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top