Ik heb een .net api-backend voor mobiele apps en de vraag kwam (in gesprek met de iOS-ontwikkelaar) of een JSON-antwoord voor een lege GUID moet teruggeven:

  • 00000000-0000-0000-0000-000000000000
  • of null (door het retourtype nullable Guid-type (Guid?)

Als de eerste is, moet de mobiele ontwikkelaar daarvoor een parse-methode maken en zijn gewone generieke null-controlefunctie niet gebruiken.

In C # zou je dat gewoon doen 

if (guid == Guid.Empty)

Maar de iOS-ontwikkelaar heeft het over het maken van een parseermethode (dus niet ingebouwd denk ik).

Maar ik kan geen enkele discussie vinden over wat als “best practice” wordt beschouwd of zelfs maar hoe native apps omgaan met lege / null-gidsen.

Ik weet het wat ik leuk vind om te doen, maar wat denk je dat ik moet doen?

Reacties

  • Ten eerste, wat ‘ s hij doet als het ‘ s niet een lege GUID? En waarom heeft hij een parse-methode nodig voor een lege maar niet een niet-lege GUID? Kan ‘ hij gewoon een gelijkheidscontrole uitvoeren met de tekenreeks ” 00000000-0000-0000-0000-000000000000 “?
  • Lege gids is anders dan niet-bestaande gids. De conventie van leeg op .Net is natuurlijk 00 … 00, maar je wilt deze conventie misschien niet lekken naar een openbare API die ‘ wordt gebruikt door andere platforms. In plaats van te proberen te definiëren wat ‘ leeg is en wat ‘ niet, moet je de betekenis definiëren van wel en niet hebben van een Guid , gebruik een conventie die gemakkelijk zou zijn voor alle platforms (web, IOS, Android, enz …) en bewaar deze als protocol.
  • @Machado nou, is het een .net-conventie? ” De ” nihil ” UUID, een speciaal geval, is de UUID ” en.wikipedia.org/wiki/Universally_unique_identifier#Standards
  • Ik vermoed dat .Net alleen Guid heeft .Leeg omdat er in release 1.0 geen generieke geneesmiddelen waren en geen Nullable < T >, dus Empty werd een standaard om null te betekenen, aangezien Guid een waardetype is, maar eigenlijk geen geldige richtlijnwaarde is. In de codebasis waar ik vandaag in werk, om de een of andere reden zijn er overal Gidsen, en zowel Empty als null betekenen semantisch hetzelfde. Het is behoorlijk vervelend, en ik ‘ heb ervoor gezorgd dat de Guid ‘ s niet-nullabel is, dus ik doe ‘ hoef niet beide gevallen te blijven controleren, maar dat ‘ is alleen omdat er ‘ een manier is om van Guid af te komen .Leeg.
  • Er ‘ is een belangrijk verschil tussen een ” leeg ” constant en null: de ene veroorzaakt NREs en de andere wint ‘ t. Beide moeten worden gecontroleerd en behandeld, dus kies je gif. Wil je snel falen of stilletjes falen?

Antwoord

Een “lege” guid is nog steeds een geldige gids , dus voor het parseren ervan is geen extra logica nodig.

De vraag is waarom je het überhaupt gebruikt? Het lijkt me een vergissing om een speciale betekenis toe te kennen aan een bepaalde guid, waardoor het een magie wordt nummer.

Het is een beetje zoals zeggen dat ik een int id zal retourneren, maar als het negatief is, is het een foutcode. Doe het niet!

.. De reden hiervoor is dat de gebruiker bij elke aanroep van uw functie moet onthouden om te controleren op een negatieve retourwaarde. Als ze het vergeten, gebeurt er een ramp.

Evenzo, als je guid.empty een speciale betekenis geeft, moet iedereen die jouw API aanroept na elke oproep een speciale cheque schrijven.

It ” Het is beter om null terug te geven (indien van toepassing) of een uitzondering te genereren (via een HTTP-foutcode, uitgaande van een REST-service).

Opmerkingen

  • omdat op een dag zul je een waarschuwingscode hebben, of een fout 504.2 en niet in staat zijn om het in een negatief geheel getal te persen, of een negatieve ID en het hele systeem zal afbrokkelen
  • het is een beetje een kant probleem echt. guid.empty (zoals elke andere specifieke guid) zal nooit worden gegenereerd
  • OP didn ‘ t ken een speciale betekenis toe tot 00..00 deed het .Net-team. De vraag is of we deze abstractie al dan niet laten lekken.
  • @RubberDuck: de nul UUID is eigenlijk onderdeel van de RFC die UUID beschrijft, dus de abstractie heeft al ” gelekt “. ref tools.ietf.org/html/rfc4122#section-4.1.7
  • Nou @Newtopian als het ‘ deel uitmaakt van de RFC, dan vind ik het volkomen acceptabel om het terug te sturen in een API-antwoord. Als de client ‘ s taal / bibliotheek geen ‘ er een constante voor definieert, ‘ is eenvoudig genoeg om er een te maken en op de juiste manier af te handelen.

Antwoord

Ik ben een iOS-ontwikkelaar en Ik heb geen idee waarom je man denkt dat hij “een parseermethode” moet maken. UUID(uuidString: valueFromServer) is alles wat hij hoeft te doen. Hij kan je magische UUID maken door simpelweg: 

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

Vervolgens kan hij elke GUID vergelijken met deze magische GUID.

Dat gezegd hebbende, voor alle waarden die van de server komen, moet de frontend-ontwikkelaar eerst controleer of de waarde aanwezig is, controleer dan of deze goed gevormd is (van het juiste type). Als je een magische waarde retourneert, moet hij ook controleren of de correct getypte waarde is magisch. Door de magische waarde op te nemen, dwing je hem om een extra if-check uit te voeren.

Als frontend-ontwikkelaar moet ik vragen: waarom dwing je mij om de complexiteit van mijn app te vergroten?

Als je een argument kunt aanvoeren dat de frontend een ontbrekende GUID anders moet behandelen dan de magische GUID, dan heb je een argument om deze terug te sturen. Anders voeg je onnodige complexiteit toe aan de frontend-app.

(Toevoeging in reactie op de opmerking van @RubberDuck.)

Hier is het ding. De JSON-standaard heeft één manier om met null-waarden om te gaan en de GUID-standaard heeft een andere manier om met null-waarden om te gaan. Aangezien u een GUID via JSON verstuurt, is dit laatste de overkoepelende zorg (omdat de GUID wordt ingepakt in JSON), is het de standaard waaraan u moet voldoen. Omdat zelfs als u besluit een null-GUID te verzenden door daadwerkelijk een GUID vol nullen te verzenden, de frontend nog steeds moet controleren op de JSON-null.

Forceer de front-end niet om met twee verschillende concepten van null om te gaan.

Opmerkingen

  • Omdat het ‘ s onderdeel van de RFC? tools.ietf.org/html/rfc4122#section-4.1.7
  • Oh de geneugten van onbedoelde complexiteit. Ik moet mijn app ingewikkelder maken omdat een of andere RFC-commissie een keuze heeft gemaakt die nergens op slaat in mijn systeem.
  • Nee, je maakt je app dus complexer dat uw systeem flexibeler wordt door een goed gedefinieerde standaard te accepteren. Ook als uw libs de standaard niet standaard ondersteunen, roept u een stank op en vraagt u hen om het stroomopwaarts op te lossen.
  • Of je laat de standaard veranderen omdat deze ‘ stom is. Magische waarden zijn de ergste. Wat nu, een RFC die zegt dat een int-waarde van 0 eigenlijk NULL is ?

Answer

Doe wat je leuk vindt (voor zover het MacOS en iOS betreft).

De iOS- of MacOS-ontwikkelaars r zal een parseermethode schrijven die controleert of uw JSON-gegevens een tekenreeks bevatten en deze in een GUID-object veranderen of op de een of andere manier een fout aangeven. Als je een JSON-null verzendt om een niet-bestaande guid aan te geven, zullen ze ook controleren of de JSON-gegevens een NSNull () -waarde bevatten. Dat veronderstelt dat de ontwikkelaar niet totaal incompetent is. Bovendien zullen ze, afhankelijk van hun voorkeur, ofwel optionele GUIDs gebruiken en op nul controleren, of niet-optionele GUIDs en een eigenschap hebben die controleert of een GUID allemaal uit nullen bestaat. Dat staat volledig los van wat je doet.

Dus serieus, je kunt doen wat je wilt (houd het gewoon consistent). Elke niet volledig incompetente ontwikkelaar komt goed. “Een parseermethode maken” is iets dat heel gemakkelijk is te doen. Zoals meestal iOS-ontwikkelaars, is dit niet eens de moeite waard om te bespreken. Documenteer wat u verzendt. Ik zal sneller een parseermethode maken dan tijdens onze discussie.

Opmerkingen

  • Ja, ik ben het met je eens, ik bepaal wat er moet gebeuren, en dat zal ik doen. En ik weet dat de iOS-ontwikkelaar in een oogwenk een parser zal maken. Maar is dit het juiste antwoord? Ik hoopte op een meer solide antwoord .. maar misschien is er ´ t een. Ik ´ laat dit een tijdje marineren en geef je dan het antwoord, er komt niets beters.

Answer

Aangezien in .NET Guid een waardetype is, kan de waarde null niet worden toegewezen.

Als we null-waarden in waardetypes moeten opslaan de normale oplossing is om Nullable te gebruiken of als afkorting de? syntaxis zoals in Guid? int? long? etc. te gebruiken.

Dit werkt ook met standaard serialisatoren, dus de waarde zal ofwel ontbreken of de letterlijke null-waarde.

Opmerkingen

  • Esben, dit antwoord heeft geen betrekking op OP ‘ s vraag. Kijk er alstublieft dieper naar voordat u antwoordt.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *