Patterns & PracticesSolutions & Design Gallery

Olá, tudo bom?

Nesse post gostaria de abordar uma solução que usei no iMusica e que pode também te ajudar com integrações baseadas em XML ou qualquer formato unquerable(neologismo). Antes de falar da solução, vou falar do problema. Nossas integrações no iMusica geralmente se dão por meio de troca de arquivos, contendo pacotes com mídia e metadados. Os metadados são armazenados em arquivos XML complexos. Independente do schema do XML usado, uns mais completos, outros mais enxutos, a quantidade de informação é colossal. O metadado do mercado fonográfico é muito extenso.

A dificuldade de manipulação desse conteúdo era gigantesco, pelos seguintes motivos:

  • Segmentação do storage
  • Necessidade de queries em arquivos
  • Acesso a grandes volumes de informação para obter dados pontuais

Toda essa complexidade fazia parte do dia-a-dia do meu time. Não que hoje ainda não faça, mas estamos trabalhando para minimizar isso. O metadado tem um destino, sempre, a manutenção de tabelas em um SGDB. Começamos a reestruturação dos serviços redesenhando os modelos de integração em uma base intermediária no SGDB, mas ao chegarmos próximos a 100 tabelas (e não havíamos mapeado sequer a metade do schema xsd) optei por abortar a ideia. Outro maluco já havia tentado fazer isso antes, e no final das contas, essa foi a terceira iniciativa, que assim como as outras, morreu! Pensei em bases XML, mas armazenar XML é extremamente insano, principalmente se comparado a formatos mais enxutos, como json. Busquei algumas bases XML, achei o Sedna e o eXist-db mas usar XQuery não foi algo motivador. Já que estava estudando sobre NoSQL tive a ideia de pesquisar sobre outras alternativas NoSQL e o resultado foi excelente.

Talvez você esteja perguntando sobre as vantagens de usar o MongoDB:

  • Queries complexas
  • Armazenamento (quase que infinito)
  • Schemaless (poupa muito trabalho)

Agora um desafio, salvar o XML, que diga-se de passagem, já vi chegar a 3mb no MongoDB.

A solução: Schemas e Geração de Código

  1. Usamos Xsd2Code para gerar as classes, em C# para mapeamento de todos as entidades e propriedades definidas no XSD. Gerou mais de 200 classes.
  2. Fazemos a leitura do XML com base em deserialização, e persistimos os mesmos objetos (classes geradas com Xsd2Code) no MongoDB.

Você poderia usar CouchBase, CouchDB, entre outras soluções, eu usei MongoDB.

Enfim, essa foi uma solução simples, e eficiente para o meu problema de integrações. Após a persistência no MongoDB, toda a minha infra que depende dos documentos, usa o MongoDB e nunca mais o XML original. Para integrações em formatos diferentes, fazemos parsers em XSLT para transformar do formato original para o formato utilizado na plataforma e assim a base de código para tratar esses documentos continua sendo a mesma.

Esses pensamentos ajudam muito a evitar segmentação em aplicações corporativas. O custo de manutenção é bem menor do que construir bases de código diferentes para realizar as mesmas coisas.

Esta não é a única solução nem cogito ser a melhor, mas foi a que me atendeu graciosamente! Espero que compartilhando contigo possa pelo menos abrir suas cabeça para ideias do tipo.

Um grande abraço e até mais!

Comente, compartilhe, curta!

Logo abaixo desse texto você encontra os Posts Relacionados, e botões de compartilhamento, em seguida a sessão de comentários!

Gostou? Então aproveite para curtir, compartilhar e enviar comentários, dúvidas ou sugestões.

Conheça o Grupo Arquitetura de Softwate | .NET: Facebook e Telegram
Luiz Carlos Faria: Site, Youtube, Facebook, Twitter, Telegram, Linkedin e Email