Jag har en .net api backend för mobilappar och frågan kom upp (i konversation med iOS-utvecklaren) om ett JSON-svar för ett tom GUID ska returnera:

  • 00000000-0000-0000-0000-0000-000000000000
  • eller null (genom att ha returtypen ogiltig Guid-typ (Guid?)

Om den första behöver mobilutvecklaren skapa en analysmetod för det och inte använda sin vanliga generiska nollkontrollfunktion.

I C # skulle du bara göra 

if (guid == Guid.Empty)

Men iOS-utvecklaren talar om att skapa en parsningsmetod (så inte inbyggd antar jag).

Men jag kan inte hitta någon diskussion om vad som anses vara ”bästa praxis” eller till och med hur inbyggda appar hanterar tomma / null-guider.

Jag vet vad jag gillar att göra men vad tycker du att jag ska göra?

Kommentarer

  • För det första vad ’ s han gör om det ’ s inte en tom GUID? Också, varför behöver han en analyseringsmetod för tom men inte en icke-tom GUID? Kan ’ t han bara göra en jämställdhetskontroll mot strängen ” 00000000-0000-0000-0000-0000-000000000000 ”?
  • Tom guide är annorlunda än guide som inte finns. På alla sätt är konventionen för tom på .Net 00 …. 00, men du kanske inte vill läcka denna konvention till ett offentligt API som ’ används av andra plattformar. Istället för att försöka definiera vad ’ är tomt och vad ’ inte är, måste du definiera innebörden av att ha och inte ha en vägledning , använd en konvention som skulle vara lätt för alla plattformar (webb, IOS, Android, etc …) och behåll den som protokoll.
  • @Machado, är det en .net-konvention? ” ” noll ” UUID, ett specialfall, är UUID ” sv.wikipedia.org/wiki/Universally_unique_identifier#Standards
  • Jag misstänker. Net har bara Guid .Töm eftersom det i 1.0-utgåvan inte fanns några generika och ingen Nullable < T >, så Tom blev en stand in för att betyda null, eftersom Guid är en värdetyp, men det är faktiskt inte ett giltigt guidvärde. I kodbasen jag jobbar med idag finns det av någon anledning guider överallt, och både Tom och null betyder semantiskt samma sak. Det är ganska irriterande, och jag ’ har gjort guiden ’ s ogiltig så jag don ’ t måste fortsätta kontrollera båda fallen, men att ’ är bara för att ’ nu är sätt att bli av med Guid . Tom.
  • ’ är en viktig skillnad mellan en ” tom ” konstant och noll: den ena orsakar NRE och den andra vann ’ t. Båda måste kontrolleras och hanteras, så välj ditt gift. Vill du misslyckas snabbt eller misslyckas tyst?

Svar

En ”tom” guid är fortfarande en giltig guide , så att analysera det borde inte kräva någon extra logik.

Frågan är varför använder du den alls? Det verkar som ett misstag för mig att tilldela en viss vägledning en särskild betydelse, vilket gör det till en magi nummer.

Det är som att säga att jag ska returnera ett int-id, men om det är negativt är det en felkod. Gör det inte!

.. Anledningen är att i varje samtal till din funktion måste användaren komma ihåg att kontrollera om det finns ett negativt returvärde. Om de glömmer inträffar katastrof.

På samma sätt, om du tilldelar guid.töm en speciell betydelse, måste alla som ringer till ditt API skriva en speciell check efter varje samtal.

Det ” det är bättre att returnera null (om det är lämpligt) eller kasta ett undantag (via en HTTP-felkod, förutsatt att en REST-tjänst).

Kommentarer

  • eftersom en dag kommer du att ha en varningskod eller ett fel 504.2 och inte kunna klämma in det i ett negativt heltal eller ett negativt id och hela systemet kommer att smula ner
  • det är lite av en sida fråga verkligen. guid.empty (som alla andra specifika guider) kommer aldrig att genereras
  • OP gjorde inte ’ t tilldelade någon speciell betydelse till 00..00 gjorde .Net-teamet. Frågan är om den här abstraktionen ska läcka eller inte.
  • @RubberDuck: noll UUID är faktiskt en del av RFC som beskriver UUID så att abstraktionen har redan ” läckte ”. ref tools.ietf.org/html/rfc4122#section-4.1.7
  • Tja @Newtopian om det ’ är en del av RFC, så tycker jag det är helt acceptabelt att returnera det i ett API-svar. Om klienten ’ språk / bibliotek inte ’ t definierar en konstant för det, ’ s är tillräckligt enkelt för att skapa en och hantera på lämpligt sätt.

Svar

Jag är en iOS-utvecklare och Jag har ingen aning om varför din kille tycker att han behöver skapa ”en analyseringsmetod.” UUID(uuidString: valueFromServer) är allt han behöver göra. Han kan skapa din magiska UUID genom att helt enkelt: 

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

Sedan kan han jämföra vilken GUID som helst med denna magiska GUID.

Med det sagt, för alla värden som kommer från servern, måste frontend-utvecklaren först kontrollera om värdet finns där, kontrollera sedan om det är välformat (av rätt typ.) Om du returnerar ett magiskt värde måste han också kontrollera om korrekt skrivet värde är magiskt. Genom att inkludera det magiska värdet tvingar du honom att göra en extra om check.

Som frontend-utvecklare måste jag fråga: Av vilken anledning tvingar du mig att öka min apps komplexitet?

Om du kan argumentera för att frontend ska behandla en saknad GUID annorlunda än den magiska GUID, har du ett argument för att returnera den. Annars lägger du till onödig komplexitet i frontend-appen.

(tillägg som svar på @RubberDucks kommentar.)

Här är saken. JSON-standarden har ett sätt att hantera nollvärden och GUID-standarden har ett annat sätt att hantera nollvärden. Eftersom du skickar en GUID via JSON , är den senare det övergripande problemet (eftersom GUID är inslagna i JSON,) är det standarden du ska följa .. Eftersom även om du bestämmer dig för att skicka en null GUID genom att faktiskt skicka en GUID full av nollor, måste frontend still kontrollera JSON-null.

Tvinga inte fronten att hantera två olika begrepp om null.

Kommentarer

  • Eftersom det ’ är en del av RFC? tools.ietf.org/html/rfc4122#section-4.1.7
  • Åh glädjen av oavsiktlig komplexitet. Jag måste göra min app mer komplex eftersom någon RFC-kommitté gjorde något val som inte är meningsfullt i mitt system.
  • Nej, du gör din app mer komplex så att ditt system blir mer flexibelt genom att acceptera en väl definierad standard. Om dina libs inte ’ inte stöder standarden, höjer du en stink och ber dem fixa den uppströms.
  • Eller så får du standarden ändrad eftersom den ’ är dum. Magiska värden är de värsta. Vad härefter, en RFC som säger ett int-värde på 0 är faktiskt NULL ?

Svar

Gör vad du gillar (när det gäller MacOS och iOS).

iOS eller MacOS utvecklas r kommer att skriva en analyseringsmetod som kontrollerar om dina JSON-data innehåller en sträng och förvandlar den till ett GUID-objekt eller på något sätt indikerar misslyckande. Om du skickar en JSON-null för att ange en icke-existerande guid kommer de också att kontrollera om JSON-data innehåller ett NSNull-värde (). Det förutsätter att utvecklaren inte är helt inkompetent. Dessutom, beroende på deras preferenser, kommer de antingen att använda valfria GUID och kontrollera om de är noll eller inte som valfria GUID och har en egenskap som kontrollerar om en GUID är alla nollor. Det är helt oberoende av vad du gör.

Så seriöst, du kan göra vad du vill (bara hålla det konsekvent). Alla inte helt inkompetenta utvecklare kommer att vara bra. ”Att skapa en tolkningsmetod” är något som görs mycket enkelt. Som mest iOS-utvecklare är det inte ens värt att diskutera. Dokumentera vad du skickar. Jag skapar en analyseringsmetod snabbare än vad vår diskussion skulle ta.

Kommentarer

  • Ja, jag håller med dig, jag styr vad som ska göras, och jag kommer att göra det. Och jag vet att iOS-utvecklaren kommer att piska upp en parser i ett ögonblick. Men är det här rätta svaret? Jag hoppades på ett mer gedigen svar .. men kanske finns det ´ t one. Jag ´ Låt detta marinera en liten stund och sedan ge dig svaret att inget bättre kommer med.

Svar

Eftersom i .NET Guid är en värdetyp kan det inte tilldelas värdet null.

Om vi behöver lagra nollor i värdetyper den normala lösningen är att använda Nullable eller som en förkortning använda? syntax som i Guid? int? long? etc.

Detta fungerar också med standardserialiserare så att värdet antingen kommer att saknas eller har bokstavligt tal nullvärde.

Kommentarer

  • Esben, detta svar adresserar inte OP ’ s fråga. Ta en djupare titt på det innan du svarar.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *