Jeg har en .net api-backend til mobilapps, og spørgsmålet kom op (i samtale med iOS-udvikleren), hvis et JSON-svar til et tom GUID skal returnere:

  • 00000000-0000-0000-0000-0000-000000000000
  • eller null (ved at have returtypen nullable Guid type (Guid?)

Hvis den første, skal mobiludvikleren oprette en parsemetode til det og ikke bruge sin almindelige generiske nulcheck-funktion.

I C # ville du bare gøre 

if (guid == Guid.Empty)

Men iOS-udvikleren taler om at oprette en parsemetode (så ikke indbygget tror jeg).

Men jeg kan ikke finde nogen diskussion om, hvad der betragtes som “bedste praksis” eller endda, hvordan native apps har at gøre med tomme / null vejledninger.

Jeg ved hvad jeg kan lide at gøre, men hvad synes du, jeg skal gøre?

Kommentarer

  • For det første hvad ‘ s han gør, hvis det ‘ s ikke en tom GUID? Også, hvorfor har han brug for en parsemetode til tom, men ikke en ikke-tom GUID? Kan ‘ t han bare foretager en ligestillingskontrol over strengen ” 00000000-0000-0000-0000-0000-000000000000 “?
  • Tom vejledning er forskellig fra ikke-eksisterende vejledning. Under alle omstændigheder er konventionen om tom på .Net 00 …. 00, men du vil muligvis ikke lække denne konvention til en offentlig API, der ‘ bruges af andre platforme. I stedet for at prøve at definere, hvad ‘ er tomt, og hvad ‘ ikke er, skal du definere betydningen af at have og ikke have en vejledning , brug en konvention, der ville være let for alle platforme (web, IOS, Android osv.), og hold den som protokollen.
  • @Machado er det en .net-konvention? ” ” nul ” UUID, en speciel sag, er UUID ” da.wikipedia.org/wiki/Universally_unique_identifier#Standards
  • Jeg formoder, at Net kun har Guid . Tom, fordi der i 1.0-udgivelsen ikke var nogen generiske stoffer og ingen ubetydelig < T >, så Tom blev en stand i at betyde nul, da Guid er en værditype, men det er faktisk ikke en gyldig guid-værdi. I kodebasen, jeg arbejder i dag, er der af en eller anden grund guider overalt, og både tom og null betyder semantisk det samme. Det er ret irriterende, og jeg har ‘ gjort Guid ‘ ikke-nulbar, så jeg don ‘ behøver ikke at fortsætte med at kontrollere begge sager, men at ‘ kun er fordi der ‘ er nu måde at slippe af med Guid . Tom.
  • Der ‘ er en vigtig forskel mellem en ” tom ” konstant og nul: den ene vil forårsage NREer og den anden vandt ‘ t. Begge skal kontrolleres og håndteres, så vælg din gift. Vil du fejle hurtigt eller mislykkes lydløst?

Svar

En “tom” guid er stadig en gyldig vejledning , så parsing, det burde ikke kræve nogen ekstra logik.

Spørgsmålet er, hvorfor bruger du det overhovedet? Det virker som en fejltagelse for mig at tildele en bestemt vejledning en særlig vejledning, hvilket gør det til en magi nummer.

Det er lidt som at sige, at jeg returnerer et int-id, men hvis det er negativt, er det en fejlkode. Gør det ikke!

.. Årsagen er, at i hvert opkald til din funktion bliver brugeren nødt til at huske at kontrollere en negativ returværdi. Hvis de glemmer, sker der en katastrofe.

Tilsvarende, hvis du tildeler guid.empty en særlig betydning, skal alle, der ringer til din API, skrive en speciel check efter hvert opkald.

Det det er bedre at returnere null (hvis det er relevant) eller smide en undtagelse (via en HTTP-fejlkode, forudsat en REST-tjeneste).

Kommentarer

  • fordi en dag vil du have en advarselskode eller en fejl 504.2 og ikke være i stand til at presse den ind i et negativt heltal eller et negativt id, og hele systemet smuldrer ned
  • det er lidt af en side spørgsmål virkelig. guid.empty (som enhver anden specifik guid) vil aldrig blive genereret
  • OP har ikke ‘ t tildelt nogen særlig betydning til 00..00, gjorde .Net-teamet. Spørgsmålet er, om denne abstraktion skal lække eller ej.
  • @RubberDuck: Nul UUID er faktisk en del af RFC, der beskriver UUID, så abstraktionen har allerede ” lækket “. ref tools.ietf.org/html/rfc4122#section-4.1.7
  • Nå @Newtopian hvis det ‘ er en del af RFC, så finder jeg det helt acceptabelt at returnere det i et API-svar. Hvis klienten ‘ s sprog / bibliotek ikke ‘ t definerer en konstant for det, er det ‘ er enkle nok til at oprette en og håndtere passende.

Svar

Jeg er en iOS-udvikler og Jeg har ingen idé om, hvorfor din fyr mener, at han har brug for at oprette “en parsingsmetode.” UUID(uuidString: valueFromServer) er alt hvad han behøver at gøre. Han kan oprette din magiske UUID ved blot at: 

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

Så kan han sammenligne enhver GUID med denne magiske GUID.

Når det er sagt, for alle værdier, der kommer fra serveren, skal frontend-udvikleren først Kontroller, om værdien er der, og kontroller derefter, om den er velformet (af den rigtige type.) Hvis du returnerer en magisk værdi, skal han også kontrollere, om korrekt indtastet værdi er magisk. Ved at inkludere den magiske værdi tvinger du ham til at foretage en ekstra hvis check.

Som frontend-udvikler er jeg nødt til at spørge: Af hvilken grund tvinger du mig til at øge kompleksiteten i min app?

Hvis du kan argumentere for, at frontend skal behandle en manglende GUID anderledes end den magiske GUID, så har du et argument for at returnere det. Ellers tilføjer du unødvendig kompleksitet til frontend-appen.

(tilføjelse som svar på @RubberDucks kommentar.)

Her er sagen. JSON-standarden har en måde at håndtere nulværdier på, og GUID-standarden har en anden måde at håndtere nulværdier på. Da du sender en GUID gennem JSON , er sidstnævnte det overordnede bekymring (fordi GUID er pakket ind i JSON,) er det den standard, du skal overholde .. Fordi selvom du beslutter at sende en null GUID ved faktisk at sende en GUID fuld af nuller, skal frontend stadig kontrollere JSON null.

Må ikke tvinge frontenden til at håndtere to forskellige begreber om null.

Kommentarer

  • Fordi det ‘ er en del af RFC? tools.ietf.org/html/rfc4122#section-4.1.7
  • Åh glæden ved utilsigtet kompleksitet. Jeg er nødt til at gøre min app mere kompleks, fordi en eller anden RFC-komité tog et valg, der ikke giver mening i mit system.
  • Nej, du gør din app mere kompleks så at dit system bliver mere fleksibelt ved at acceptere en veldefineret standard. Hvis dine libs ikke ‘ ikke understøtter standarden, hæver du en stink og beder dem om at rette den opstrøms.
  • Eller får du ændret standarden, fordi den ‘ er stum. Magiske værdier er de værste. Hvad næste, en RFC, der siger en int-værdi på 0, er faktisk NULL ?

Svar

Gør hvad du kan lide (hvad MacOS og iOS angår).

iOS eller MacOS udvikler sig r skriver en parsemetode, der kontrollerer, om dine JSON-data indeholder en streng, og omdanner dem til et GUID-objekt eller på en eller anden måde angiver fejl. Hvis du sender en JSON-nul for at angive en ikke-eksisterende vejledning, kontrollerer de også, om JSON-dataene indeholder en NSNull () -værdi. Det antages, at udvikleren ikke er helt inkompetent. Derudover, afhængigt af deres præference, bruger de enten valgfri GUIDer og kontrollerer for nul eller ikke-valgfri GUIDer og har en egenskab, der kontrollerer, om en GUID er alle nuller. Det “er helt uafhængigt af, hvad du laver.

Så seriøst, du kan gøre, hvad du kan lide (bare hold det konsistent). Enhver ikke helt inkompetent udvikler vil være helt fint.” Oprettelse af en parsingmetode “er noget der gøres meget let. Som mest iOS-udvikler er det ikke engang værd at diskutere. Dokumenter, hvad du sender. Jeg opretter en parsemetode hurtigere end vores diskussion ville tage.

Kommentarer

  • Ja, jeg er enig med dig, jeg styrer, hvad der skal gøres, og jeg vil. Og jeg ved, at iOS-udvikleren pisker op en parser i en smule. Men er dette det rigtige svar? Jeg håbede på et mere solidt svar .. men måske er der ´ t one. Jeg ´ Lad dette marinere i et stykke tid og derefter give dig svaret, der kommer ikke noget bedre.

Svar

Da i. NET Guid er en værditype, kan den ikke tildeles værdien nul.

Hvis vi har brug for at gemme nuller i værdityper den normale løsning er at bruge Nullable eller som en stenografi bruge? syntaksen som i Guid? int? long? osv.

Dette fungerer også med standard serializers, så værdien enten mangler eller har den bogstavelige nulværdi.

Kommentarer

  • Esben, dette svar adresserer ikke OP ‘ s spørgsmål. Se nærmere på det, inden du svarer.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *