Tenho um back-end de API .net para aplicativos móveis e surgiu a pergunta (em conversa com o desenvolvedor iOS) se uma resposta JSON para um GUID vazio deve retornar:

  • 00000000-0000-0000-0000-000000000000
  • ou null (por ter o tipo de retorno anulável tipo Guid (Guid?)

Se for o primeiro, o desenvolvedor móvel precisa criar um método de análise para isso e não usar sua função normal de verificação de nulos genérica.

Em C #, você apenas faria 

if (guid == Guid.Empty)

Mas o desenvolvedor iOS fala sobre a criação de um método de análise (portanto, não inclua, eu acho).

Mas eu não consigo encontrar nenhuma discussão sobre o que é considerado “melhor prática” ou mesmo como os aplicativos nativos estão lidando com Guid “s vazios / nulos.

Eu sei o que gosto de fazer, mas o que você acha que devo fazer?

Comentários

  • Em primeiro lugar, o que ‘ ele faz se ‘ não um GUID vazio? Além disso, por que ele precisa de um método de análise para um GUID vazio, mas não um não vazio? Pode ‘ ele apenas fazer uma verificação de igualdade em relação à string ” 00000000-0000-0000-0000-000000000000 “?
  • Guid vazio é diferente de Guid não existente. Sem dúvida, a convenção de vazio em .Net é 00 …. 00, mas você pode não querer vazar essa convenção para uma API pública que ‘ é usada por outras plataformas. Em vez de tentar definir o que ‘ está vazio e o que ‘ não é, você deve definir o significado de ter e não ter um Guid , use uma convenção que seja fácil para todas as plataformas (web, IOS, Android, etc …) e mantenha-a como o protocolo.
  • @Machado bem, é uma convenção .net? ” O ” nil ” UUID, um caso especial, é o UUID ” en.wikipedia.org/wiki/Universally_unique_identifier#Standards
  • Suspeito que .Net só tem Guid .Empty porque na versão 1.0 não havia genéricos e nenhum Nullable < T >, então Empty tornou-se um substituto para significar nulo, já que Guid é um tipo de valor, mas não é realmente um valor guid válido. Na base de código em que trabalho hoje, por algum motivo, há Guid? S por toda parte, e ambos, vazio e nulo, semanticamente significam a mesma coisa. É muito chato e eu ‘ tornei o Guid ‘ não anulável, então não ‘ não preciso ficar verificando os dois casos, mas isso ‘ s apenas porque há ‘ agora uma maneira de se livrar do Guid . Vazio.
  • Há ‘ s uma diferença importante entre um ” vazio ” constante e nula: um causará NREs e o outro vencerá ‘ t. Ambos precisam ser verificados e manipulados, então escolha seu veneno. Quer falhar rápido ou silenciosamente?

Resposta

Um guid “vazio” ainda é um guid válido , portanto, analisá-lo não deve exigir nenhuma lógica extra.

A questão é por que você está usando isso? Parece um erro para mim atribuir um significado especial a um guia específico, tornando-o mágico número.

É um pouco como dizer que retornarei um int id, mas se for negativo, é um código de erro. Não faça isso!

..A razão é que em cada chamada para sua função, o usuário terá que se lembrar de verificar se há um valor de retorno negativo. Se eles esquecerem, ocorrerá um desastre.

Da mesma forma, se você atribuir a guid.empty um significado especial, todos os que chamam sua API terão que fazer uma verificação especial após cada chamada.

Isso ” É melhor retornar nulo (se apropriado) ou lançar uma exceção (por meio de um código de erro HTTP, assumindo um serviço REST).

Comentários

  • porque um dia você terá um código de aviso, ou um erro 504.2 e não será capaz de espremê-lo em um número inteiro negativo, ou um id negativo e todo o sistema desmoronará
  • é um pouco um lado realmente. guid.empty (como qualquer outro guid específico) nunca será gerado
  • OP didn ‘ t atribuir qualquer significado especial a 00..00, a equipe .Net fez. A questão é se devemos ou não deixar essa abstração vazar.
  • @RubberDuck: o UUID nulo é na verdade parte do RFC que descreve o UUID, então a abstração tem já ” vazou “. ref tools.ietf.org/html/rfc4122#section-4.1.7
  • Bem, @Newtopian, se ‘ faz parte do RFC, acho totalmente aceitável retorná-lo em uma resposta da API. Se a ‘ linguagem / biblioteca do cliente não ‘ definir uma constante para ela, ela ‘ é simples o suficiente para criar um e manipulá-lo de maneira adequada.

Resposta

Sou um desenvolvedor iOS e Não tenho ideia de por que seu cara acha que precisa criar “um método de análise”. UUID(uuidString: valueFromServer) é tudo o que ele precisa fazer. Ele pode criar seu UUID mágico simplesmente: 

extension UUID { static var zero: UUID { return UUID(uuidString: "00000000-0000-0000-0000-000000000000")! } }

Então ele pode comparar qualquer GUID a este GUID mágico.

Dito isso, para todos os valores que vêm do servidor, o desenvolvedor de front-end deve primeiro verifique se o valor está lá e, em seguida, verifique se está bem formado (do tipo certo). Se você estiver retornando um valor mágico, ele deve também verificar se o o valor digitado corretamente é mágico. Ao incluir o valor mágico, você o está forçando a fazer uma verificação adicional de if.

Como desenvolvedor front-end, devo perguntar: por que motivo você está me forçando a aumentar a complexidade do meu aplicativo?

Se você puder argumentar que o frontend deve tratar um GUID ausente de maneira diferente do que o GUID mágico, então você tem um argumento para devolvê-lo. Caso contrário, você estará adicionando complexidade desnecessária ao aplicativo de front-end.

(Adição em resposta ao comentário de @RubberDuck.)

Aqui está o problema. O padrão JSON tem uma maneira de lidar com valores nulos e o padrão GUID tem uma maneira diferente de lidar com valores nulos. Como você está enviando um GUID por meio de JSON , o último é a preocupação geral (porque o GUID está sendo agrupado em JSON), é o padrão que você deve seguir. Porque, mesmo que você decida enviar um GUID nulo, enviando na verdade um GUID cheio de zeros, o front-end ainda precisa verificar o nulo JSON.

Não force o front end a lidar com dois conceitos diferentes de nulo.

Comentários

  • Porque ‘ s parte do RFC? tools.ietf.org/html/rfc4122#section-4.1.7
  • Oh, as alegrias da complexidade acidental. Tenho que tornar meu aplicativo mais complexo porque algum comitê RFC fez alguma escolha que não faz sentido no meu sistema.
  • Não, você torna seu aplicativo mais complexo, então para que seu sistema se torne mais flexível ao aceitar um padrão bem definido. Além disso, se suas bibliotecas não ‘ suportam nativamente o padrão, você levanta um mau cheiro e pede que eles o corrijam.
  • Ou você muda o padrão porque ele ‘ é burro. Valores mágicos são os piores. O que vem a seguir, um RFC que diz que um valor int de 0 é na verdade NULL ?

Resposta

Faça o que quiser (no que diz respeito a MacOS e iOS).

O desenvolvedor iOS ou MacOS r escreverá um método de análise que verifica se seus dados JSON contêm uma string e os transforma em um objeto GUID ou de alguma forma indica falha. Se você enviar um JSON nulo para indicar um guid inexistente, eles também verificarão se os dados JSON contêm um valor NSNull (). Isso presumindo que o desenvolvedor não seja totalmente incompetente. Além disso, dependendo de sua preferência, eles usarão GUIDs opcionais e verificarão se há zero, ou GUIDs não opcionais e terão uma propriedade que verifica se um GUID contém apenas zeros. Isso é totalmente independente do que você faz.

Então, a sério, você pode fazer o que quiser (apenas mantenha a consistência). Qualquer desenvolvedor que não seja totalmente incompetente ficará bem. “Criar um método de análise” é algo que é feito com muita facilidade. Como desenvolvedor de iOS, isso nem vale a pena discutir. Documente o que você está enviando. Vou criar um método de análise mais rápido do que nossa discussão levaria.

Comentários

  • Sim, concordo com você, eu controlo o que deve ser feito, e eu irei. E eu sei que o desenvolvedor iOS irá preparar um analisador em um instante. Mas esta é a resposta certa? Eu esperava uma resposta mais sólida .. mas talvez haja ´ t one. Eu ´ vou deixar isso marinar por um tempo e então dar a você a resposta, nada melhor vem junto.

Resposta

Como no .NET Guid é um tipo de valor, não pode ser atribuído o valor nulo.

Se precisarmos armazenar nulos em tipos de valor a solução normal é usar Nullable ou como uma abreviação usar a? sintaxe como em Guid? int? long? etc.

Isso também funcionará com serializadores padrão, então o valor estará ausente ou terá o literal valor nulo.

Comentários

  • Esben, esta resposta não aborda OP ‘ s pergunta. Analise-o com mais atenção antes de responder.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *