Digitação dinâmica em toda a pilha de tecnologia - onde reforçar a validade dos dados?

5

Nos últimos dois anos, venho jogando com novas tecnologias em meus projetos paralelos. Como desenvolvedor da Web, passei do seguinte (e ainda o seguinte, no trabalho):

A pilha de tecnologia 'clássica'

  1. Formulários de POSTs do navegador da Web para ...
  2. um servidor do aplicativo da web codificado por C #, comunicando-se com ...
  3. serviços externos via XML, então, finalmente ...
  4. escrevendo o estado do aplicativo em um banco de dados SQL.

Para usar um acordo bem diferente:

A pilha de tecnologia totalmente dinâmica

  1. Navegador da Web enviando XmlHttpRequests para ...
  2. um servidor Node.js codificado em JavaScript, comunicando-se com ...
  3. outros serviços externos via serviços RESTful em JSON, em última análise ...
  4. escrevendo o estado do aplicativo em um banco de dados no-SQL

Chegou ao ponto em que minha pilha inteira tem absolutamente sem aplicação de tipo ou esquema, em qualquer lugar .

Agora, isso foi ótimo antes, ao consumir os serviços da Web de outras pessoas. Pode até ter sido bom até os bancos de dados SQL terem sido abandonados (junto com seus esquemas de banco de dados). Mas agora estou preso em:

Onde declarativo defino qual é a estrutura válida dos dados do meu domínio de negócios?

Eu quero reforçar a validade de dados antes de disponibilizar publicamente qualquer um dos meus projetos - afinal, o que impediria alguém de apenas enviar dados inválidos para meus serviços e usar tudo isso apenas como um provedor de banco de dados livre de hackers? Em algum ponto, deve ser imposto que "este serviço da Web aceitará apenas uma coleção de pelo menos um X. X deve conter A, B e, opcionalmente, C".

A primeira solução que pensei foi fazer validação dentro do meu node.js, através de um grande bloco de código imperativo / if-elses / etc. Isso parece errado.

Eu tenho usado o CouchDB e, por um tempo, achei que seria melhor colocar esse código de validação nos manipuladores _update . Pelo menos estamos realizando validação como parte da persistência, mas ainda é um bloqueio imperativo feio.

Em seguida, examinei as linguagens de esquema JSON. Não há nenhum padrão, tanto quanto eu posso ver, e eu não estava confiante nas múltiplas soluções oferecidas. Eu poderia criar o meu próprio, mas só estaria expandindo o corpo de linguagens de esquema JSON não padrão.

XML? Eu poderia colocar o X de volta no AJAX e tê-los todos validados pelo esquema no lado do servidor. Isso não parece seguir as tendências no desenvolvimento de software, no entanto. Nenhum deles usaria um armazenamento de dados XML em vez de uma camada de persistência do JSON CouchDB / BSON MongoDB.

Então, estou preso. Idéias?

TL; DR Onde defino declarativamente a estrutura válida dos dados do meu domínio de negócio quando não estou usando nenhuma linguagem estática orientada a objeto e nenhum banco de dados SQL vinculado a esquema na minha pilha de tecnologia? É possível que haja algum tipo de tipagem estática (ou esquema de banco de dados, ou XML validado) em algum lugar para uma pilha de tecnologia fazer algum sentido? Se sim, onde?

    
por Stoive 10.05.2012 / 06:46
fonte

3 respostas

4

Parece-me que você está prestes a criar uma plataforma interna para compensar a falta de semântica inerente à a língua que você escolheu.

Até mesmo definições de esquema (seja XML DTD ou esquema JSON ou esquema de mongoose ) não fornecerá a você a segurança da análise estática. Tudo o que você realmente pode usá-los é garantir que seu sistema não se depare silenciosamente com comportamento indefinido e acabe falhando.

Não sei ao certo por que você não usa um idioma, isso simplesmente fornece isso imediatamente. Usando uma linguagem tipada dinamicamente e embutindo restrições de tipo em que parece combinar o pior dos dois mundos. Ainda mais, porque as modernas linguagens estaticamente tipadas são capazes de inferir vastas partes dessas restrições implicitamente.

Pessoalmente, sugiro que você dê uma olhada em Haxe 's Backend JavaScript . Existe um site dedicado ao desenvolvimento de node.js com o Haxe - você pode começar por aí. Os tipos anônimos do Haxe podem ser usados rapidamente para vincular fontes JSON de maneira segura, sem qualquer sobrecarga de tempo de execução. Ainda assim, se você desejar, suas instalações de metaprogramação permitirão que você gere automaticamente código de validação a partir do momento da compilação.

Claro que o Haxe não é de longe a única opção disponível para direcionar JavaScript de maneira segura. Então, se você acha que precisa dos benefícios da tipagem estática, você deve investir tempo para encontrar uma linguagem de sua preferência, que realmente incorpore essas informações diretamente em sua semântica estaticamente analisável.

    
por 10.05.2012 / 08:03
fonte
2

Deixe de lado a noção de tipos.

O ponto principal da digitação dinâmica, pelo menos em idiomas que acertam, é que você não precisa pensar em tipos na maioria das vezes. Verificações de tipo fazem sentido em uma linguagem pré-compilada, porque o compilador pode capturar muitos erros antes mesmo de tentar executar o código, mas quando o código é interpretado ou compilado pelo JIT, os benefícios das verificações de tipo estático são marginal e não pesam contra a flexibilidade adicional que a programação dinâmica tem a oferecer.

Em vez de validar tipos, valide os valores - isto é, se você quiser que algo seja numérico, execute uma verificação 'é numérica'. Se você quiser que algo tenha uma determinada propriedade, verifique se a propriedade existe. Se você quiser que algo esteja em um determinado intervalo, verifique se está de fato dentro do intervalo. Etc etc.

Existem duas filosofias: o mais tradicional check-before-you-go, ou seja, antes de dividir a por b , você garante que b seja diferente de zero; e a rota mais fácil de pedir perdão do que a permissão que o Python usa, ou seja, você apenas divide a por b e depois captura a exceção dividir por zero posteriormente.

Infelizmente, não há nenhuma maneira significativa de fazer isso de forma declarativa que eu saiba. Mas, a fronteira entre código e dados é muito mais desfocada na programação dinâmica - o código também é dado que você pode manipular e os dados podem assumir o papel de código. Uma parte do código javascript que valida um objeto JSON é apenas mais um pedaço de texto, e você pode tratá-lo como simples dados antigos; você pode até mesmo gerar esse texto em tempo de execução e depois executá-lo (embora você deva ser muito cuidadoso com isso, especialmente se usar dados de fontes não confiáveis no processo de geração de código).

No que diz respeito aos esquemas, verificar rigorosamente se um determinado objeto JSON corresponde a um esquema raramente é necessário. Em vez disso, basta verificar se as propriedades necessárias estão lá e se as invariantes de nível de valor são válidas. Se existirem propriedades extras, tudo bem - você simplesmente as ignora. Se algo estiver faltando, você pode resgatar ou substituir um valor padrão. E se algo tem o tipo errado, novamente, você pode liberar (encontrou uma string não numérica onde um número era esperado), ou você pode recuperar (substituir um valor padrão, arredondar, truncar, converter para booleano, etc.).

Outra coisa a considerar é que o XML é muito mais complexo do que o JSON - o XML possui namespaces, atributos, entidades e você precisa decidir como empacotar entre objetos em sua linguagem e representações XML. Em JSON, a escolha geralmente é óbvia - é escalar (int, float, string, booleano, nulo), uma lista simples (matriz) ou uma coleção de valor-chave (objeto).

Infelizmente, existem poucas linguagens (se houver) que obtêm tipos de conversão transparentes - Javascript, PHP, Python, todas elas exigem um tipo explícito de malabarismo ocasionalmente, portanto você não será capaz de alcançar a situação ideal ideal.

    
por 10.05.2012 / 08:00
fonte
2

Bem, como sua pilha de programação não se importa com os tipos, por que você deveria.

A resposta é que seus usuários podem. Então, o que você quer fazer é impor quaisquer regras comerciais aplicáveis aos seus dados.

Isso pode ser feito por JavaScript nos formulários digitados, codificando a validação no código do servidor Node.js quando uma solicitação é recebida ou, até mesmo codificando as regras em xsd e obtendo o analisador para validar sua entrada xml.

O ponto é que você implementa a validação de regras de negócios e não a validação técnica. Ou seja, você deve verificar regras como "Um número de três dígitos entre 001 e 700", o que significa algo para o usuário final, em vez de "é este numérico". Portanto, se o usuário achar que "A noite anterior ao Natal" é uma data válida e seu aplicativo pode conviver com ela, é uma data válida.

    
por 10.05.2012 / 08:36
fonte