Jeg har en .net api backend for mobilapper, og spørsmålet kom opp (i samtale med iOS-utvikleren) hvis et JSON-svar for et tom GUID skal returnere:

  • 00000000-0000-0000-0000-0000-000000000000
  • eller null (ved å ha returtypen nullbar Veiledningstype (Veiledning?)

Hvis den første, må mobilutvikleren lage en analyseringsmetode for det og ikke bruke sin vanlige generiske nullkontrollfunksjon.

I C # ville du bare gjort 

if (guid == Guid.Empty)

Men iOS-utvikleren snakker om å lage en analysemetode (så ikke bygg inn antar jeg).

Men jeg kan ikke finne noen diskusjon om hva som regnes som «beste praksis» eller til og med hvordan innfødte apper har å gjøre med tomme / null veiledninger.

Jeg vet hva jeg liker å gjøre, men hva synes du jeg burde gjøre?

Kommentarer

  • For det første hva ‘ s han gjør hvis det ‘ s ikke en tom GUID? Også, hvorfor trenger han en analyseringsmetode for tom, men ikke en ikke-tom GUID? Kan ‘ t han bare foretar en likhetskontroll mot strengen » 00000000-0000-0000-0000-0000-000000000000 «?
  • Tom veiledning er forskjellig fra ikke-eksisterende veiledning. For all del er konvensjonen om tom på .Net 00 …. 00, men du vil kanskje ikke lekke denne konvensjonen til et offentlig API som ‘ brukes av andre plattformer. I stedet for å prøve å definere hva ‘ er tomt og hva ‘ ikke er, må du definere betydningen av å ha og ikke ha en veiledning , bruk en konvensjon som ville være enkel for alle plattformer (web, IOS, Android, osv …) og hold den som protokoll.
  • @Machado vel, er det en .net-konvensjon? » » null » UUID, et spesielt tilfelle, er UUID » no.wikipedia.org/wiki/Universally_unique_identifier#Standards
  • Jeg mistenker. Net har bare veiledning .Tom fordi det i 1.0-utgivelsen ikke var noen generiske stoffer og ingen Nullable < T >, så Tom ble en stand i å bety null, siden Guid er en verditype, men det er faktisk ikke en gyldig guid-verdi. I kodebasen jeg jobber i dag, av en eller annen grunn er det guider overalt, og både tom og null betyr semantisk det samme. Det er ganske irriterende, og jeg har ‘ gjort veiledningen ‘ ikke-nullbar, så jeg gjør ikke ‘ t må fortsette å sjekke begge sakene, men at ‘ bare fordi det ‘ er nå måte å bli kvitt Guid . Tom.
  • Der ‘ er en viktig forskjell mellom en » tom » konstant og null: den ene vil forårsake NRE-er og den andre vant ‘ t. Begge må sjekkes og håndteres, så velg giftet ditt. Vil du mislykkes raskt, eller mislykkes stille?

Svar

En «tom» guid er fortsatt en gyldig guide , så å analysere det burde ikke kreve ekstra logikk.

Spørsmålet er hvorfor bruker du det i det hele tatt? Det virker som en feil for meg å tilordne en spesiell veiledning spesiell betydning, noe som gjør det til en magi nummer.

Det er litt som å si at jeg vil returnere et int-id, men hvis det er negativt, er det en feilkode. Ikke gjør det!

.. Årsaken er at i hver samtale til funksjonen din, må brukeren huske å sjekke for en negativ returverdi. Hvis de glemmer, oppstår katastrofe.

På samme måte, hvis du tildeler guid.empty en spesiell betydning, må alle som ringer API-en din skrive en spesiell sjekk etter hver samtale.

It » er bedre å returnere null (hvis aktuelt) eller kaste et unntak (via en HTTP-feilkode, forutsatt en REST-tjeneste).

Kommentarer

  • fordi en dag vil du ha en advarselskode, eller en feil 504.2 og ikke være i stand til å presse den inn i et negativt heltall, eller en negativ id, og hele systemet vil smuldre ned
  • det er litt av en side problemet virkelig. guid.empty (som alle andre spesifikke guid) vil aldri bli generert
  • OP didn ‘ t tildelte noen spesiell betydning til 00..00 gjorde .Net-teamet. Spørsmålet er om denne abstraksjonen skal lekke eller ikke.
  • @ RubberDuck: null UUID er faktisk en del av RFC som beskriver UUID så abstraksjonen har allerede » lekket «. ref tools.ietf.org/html/rfc4122#section-4.1.7
  • Vel @Newtopian hvis det ‘ er en del av RFC, så synes jeg det er helt akseptabelt å returnere det i et API-svar. Hvis klienten ‘ s språk / bibliotek ikke ‘ t definerer en konstant for det, er det ‘ er enkle nok til å lage en og håndtere riktig.

Svar

Jeg er en iOS-utvikler og Jeg aner ikke hvorfor fyren din mener at han trenger å lage «en analyseringsmetode.» UUID(uuidString: valueFromServer) er alt han trenger å gjøre. Han kan lage din magiske UUID ved å bare: 

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

Så kan han sammenligne hvilken som helst GUID med denne magiske GUIDEN.

Når det er sagt, for alle verdier som kommer fra serveren, må frontend-utvikleren først sjekk om verdien er der, og sjekk deretter om den er godt formet (av riktig type.) Hvis du returnerer en magisk verdi, må han også sjekke for å se om riktig skrevet verdi er magi. Ved å inkludere den magiske verdien tvinger du ham til å foreta en ekstra hvis sjekk.

Som frontend-utvikler må jeg spørre: Av hvilken grunn tvinger du meg til å øke kompleksiteten i appen min? / p>

Hvis du kan argumentere for at frontend skal behandle en manglende GUID annerledes enn den magiske GUID, så har du et argument for å returnere den. Ellers legger du til unødvendig kompleksitet i frontend-appen.

(Tillegg som svar på @RubberDucks kommentar.)

Her er saken. JSON-standarden har en måte å håndtere nullverdier på, og GUID-standarden har en annen måte å håndtere nullverdier på. Siden du sender en GUID gjennom JSON , er sistnevnte overordnet bekymring (fordi GUID pakkes inn i JSON,) er det standarden du bør overholde .. For selv om du bestemmer deg for å sende en null GUID ved faktisk å sende en GUID full av nuller, må frontend fortsatt sjekke om JSON null er.

Ikke tving frontenden til å håndtere to forskjellige begreper null.

Kommentarer

  • Fordi det ‘ er en del av RFC? tools.ietf.org/html/rfc4122#section-4.1.7
  • Å gleden ved utilsiktet kompleksitet. Jeg må gjøre appen min mer kompleks fordi noen RFC-komiteer tok et valg som ikke gir mening i systemet mitt.
  • Nei, du gjør appen din mer kompleks så at systemet ditt blir mer fleksibelt ved å akseptere en veldefinert standard. Hvis libs ikke støtter ‘ t naturlig støtter standarden, løfter du en stink og ber dem om å fikse den oppstrøms. / li>
  • Eller får du endret standarden fordi den ‘ er dum. Magiske verdier er de verste. Hva neste, en RFC som sier en int-verdi på 0 er faktisk NULL ?

Svar

Gjør det du liker (når det gjelder MacOS og iOS).

iOS eller MacOS utvikles r vil skrive en parsingsmetode som sjekker om JSON-dataene inneholder en streng og gjør det til et GUID-objekt eller på en eller annen måte indikerer feil. Hvis du sender en JSON-null for å indikere en ikke-guid, vil de også sjekke om JSON-dataene inneholder en NSNull () -verdi. Det antas at utvikleren ikke er helt inhabil. I tillegg, avhengig av deres preferanse, vil de enten bruke valgfrie GUIDer og sjekke for null eller ikke-valgfrie GUIDer og har en egenskap som sjekker om en GUID er alle nuller. Det er helt uavhengig av hva du gjør.

Så seriøst, du kan gjøre det du vil (bare hold det konsistent). Enhver ikke helt inhabil utvikler vil være helt greit. «Å lage en analyseringsmetode» er noe som gjøres veldig enkelt. Som mest iOS-utvikler er dette ikke engang verdt å diskutere. Dokumenter hva du sender. Jeg oppretter en analyseringsmetode raskere enn det diskusjonen vår ville ta.

Kommentarer

  • Ja, jeg er enig med deg, jeg kontrollerer hva som skal gjøres, og jeg vil. Og jeg vet at iOS-utvikleren vil piske opp en parser i en blikk. Men er dette det riktige svaret? Jeg håpet på et mer solid svar .. men kanskje det er ´ t one. Jeg ´ La dette marinere en liten stund og gi deg svaret, ingenting bedre kommer sammen.

Svar

Siden i .NET Guid er en verditype, kan den ikke tildeles verdien null.

Hvis vi trenger å lagre null i verdityper den normale løsningen er å bruke Nullable eller som en stenografi bruke? syntaksen som i Guid? int? long? osv.

Dette vil også fungere med standard serialisatorer slik at verdien enten vil mangle eller ha bokstavelig nullverdi.

Kommentarer

  • Esben, dette svaret adresserer ikke OP ‘ spørsmål. Ta en dypere titt på den før du svarer.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *