Am un backend api .net pentru aplicații mobile și întrebarea a apărut (în conversație cu dezvoltatorul iOS) dacă un răspuns JSON pentru un GUID gol ar trebui să revină:

  • 00000000-0000-0000-0000-00000000000000
  • sau null (având tipul de returnare nul tip Guid (Guid?)

Dacă este primul, dezvoltatorul de telefonie mobilă trebuie să creeze o metodă de analiză pentru aceasta și să nu folosească funcția sa generală de verificare a nulului.

În C # ați face doar 

if (guid == Guid.Empty)

Dar dezvoltatorul iOS vorbește despre crearea unei metode de analiză (așa că nu încorporez, cred).

Dar eu nu pot găsi nicio discuție despre ceea ce este considerat „cea mai bună practică” sau chiar despre modul în care aplicațiile native au de-a face cu Ghidul gol / nul.

Știu ce îmi place să fac, dar ce crezi că ar trebui să fac?

Comentarii

  • În primul rând, ce face ‘ dacă face ‘ s nu un GUID gol? De asemenea, de ce are nevoie de o metodă de analiză pentru gol, dar nu un GUID ne-gol? Poate ‘ să facă doar o verificare a egalității cu șirul ” 00000000-0000-0000-0000-000000000000 „?
  • Ghidul gol este diferit de ghidul inexistent. Cu siguranță, convenția de gol pe .Net este 00 … 00, dar este posibil să nu doriți să scurgeți această convenție către un API public care ‘ este utilizat de alte platforme. În loc să încercați să definiți ce ‘ este gol și ce ‘ nu, trebuie să definiți sensul de a avea și de a nu avea un Guid , utilizați o convenție care ar fi ușoară pentru toate platformele (web, IOS, Android, etc …) și păstrați-o ca protocol.
  • @Machado bine este o convenție .net? ” ” zero ” UUID, un caz special, este UUID ” en.wikipedia.org/wiki/Universally_unique_identifier#Standards
  • Bănuiesc că .Net are doar Guid .Goliu, deoarece în versiunea 1.0 nu existau generice și nu exista Nullable < T >, astfel încât Empty a devenit un stand în care înseamnă nul deoarece Guid este un tip de valoare, dar nu este de fapt o valoare de valid validă. În baza de coduri în care lucrez astăzi, dintr-un motiv oarecare există Guid-uri peste tot, și atât Gol, cât și nul înseamnă semantic același lucru. Este destul de enervant și ‘ am făcut ca Guid ‘ să nu poată fi anulate, așa că nu ‘ nu trebuie să verificați în continuare ambele cazuri, dar ‘ este doar pentru că există acum ‘ modalitate de a scăpa de Guid .Goliu.
  • Există ‘ o diferență importantă între un ” gol ” constantă și nulă: una va provoca NRE-uri, iar cealaltă va câștiga ‘ t. Ambele trebuie verificate și manipulate, așa că alegeți-vă otravă. Doriți să eșuați rapid sau să eșuați în tăcere?

Răspundeți

Un ghid „gol” este încă un ghid valid , deci analizarea acestuia nu ar trebui să necesite nicio logică suplimentară.

Întrebarea este de ce o folosiți deloc? Mi se pare o greșeală să atribuiți un sens special unui anumit ghid, făcându-l o magie număr.

Este un pic ca și cum ați spune că voi returna un ID int, dar dacă este negativ, atunci este un cod de eroare. Nu o faceți!

..Motivul este că, în fiecare apel către funcția dvs., utilizatorul va trebui să-și amintească să verifice o valoare de returnare negativă. Dacă uită, apare un dezastru.

În mod similar, dacă atribuiți guid.empty o semnificație specială, oricine apelează API-ul dvs. trebuie să scrie un cec special după fiecare apel.

Este ” Este mai bine să returnați nul (dacă este cazul) sau să aruncați o excepție (printr-un cod de eroare HTTP, presupunând un serviciu REST).

Comentarii

  • deoarece într-o zi veți avea un cod de avertizare sau o eroare 504.2 și nu veți putea să-l strângeți într-un număr întreg negativ sau un id negativ și întregul sistem se va prăbuși
  • este un pic o parte problema într-adevăr. guid.empty (ca orice alt ghid specific) nu va fi generat niciodată
  • OP nu ‘ t a atribuit nicio semnificație specială până la 00..00, echipa .Net a făcut-o. Întrebarea este dacă se lasă sau nu scurgerea acestei abstractizări.
  • @RubberDuck: UUID nul este de fapt parte a RFC care descrie UUID, astfel încât abstractizarea are deja ” scurs „. ref tools.ietf.org/html/rfc4122#section-4.1.7
  • Ei bine @Newtopian dacă ‘ face parte din RFC, atunci consider complet acceptabil să îl returnez într-un răspuns API. Dacă limbajul / biblioteca clientului ‘ nu definește o constantă pentru aceasta, ‘ este suficient de simplu pentru a crea unul și pentru a se descurca corespunzător.

Răspuns

Sunt un dezvoltator iOS și Nu am idee de ce tipul tău crede că trebuie să creeze „o metodă de analiză”. UUID(uuidString: valueFromServer) este tot ce trebuie să facă. El îți poate crea UUID-ul magic, pur și simplu: 

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

Apoi poate compara orice GUID cu acest GUID magic.

Acestea fiind spuse, pentru toate valorile care vin de la server, dezvoltatorul frontend trebuie mai întâi verificați dacă valoarea este acolo, apoi verificați dacă este bine formată (de tipul potrivit). Dacă întoarceți o valoare magică, el trebuie să și verifice pentru a vedea dacă valoarea corect tastată este magie. Prin includerea valorii magice, îl obligați să facă o verificare suplimentară dacă.

În calitate de dezvoltator frontend, trebuie să întreb: Din ce motiv mă obligați să măresc complexitatea aplicației mele?

Dacă puteți argumenta că frontendul ar trebui să trateze un GUID lipsă diferit decât GUID-ul magic, atunci aveți un argument pentru returnarea acestuia. În caz contrar, adăugați o complexitate inutilă aplicației frontend.

(Adăugare ca răspuns la comentariul lui @RubberDuck.)

Aici este vorba. Standardul JSON are un mod de a trata valorile nule, iar standardul GUID are un mod diferit de a trata valorile nule. Deoarece trimiteți un GUID prin JSON , acesta din urmă este preocuparea generală (deoarece GUID este înfășurat în JSON), este standardul la care ar trebui să vă conformați .. Deoarece, chiar dacă decideți să trimiteți un GUID nul, trimițând efectiv un GUID plin de zerouri, frontend-ul încă trebuie să verifice dacă este nul JSON.

Nu forțați front end-ul să se ocupe de două concepte diferite de nul.

Comentarii

  • Deoarece ‘ parte a RFC? tools.ietf.org/html/rfc4122#section-4.1.7
  • Oh bucuriile complexității accidentale. Trebuie să-mi fac aplicația mai complexă, deoarece un comitet RFC a făcut o alegere care nu are sens în sistemul meu.
  • Nu, tu îți faci aplicația mai complexă, așa că că sistemul dvs. devine mai flexibil acceptând un standard bine definit. De asemenea, dacă libs-urile dvs. nu ‘ nu acceptă în mod nativ standardul, ridicați puterea și le cereți să îl repare în amonte.
  • Sau veți obține modificarea standardului, deoarece este ‘ prost. Valorile magice sunt cele mai rele. Ce urmează, un RFC care spune o valoare int de 0 este de fapt NULL ?

Răspuns

Fă ceea ce îți place (în ceea ce privește MacOS și iOS).

iOS sau MacOS se dezvoltă r va scrie o metodă de analiză care verifică dacă datele JSON conțin un șir și îl transformă într-un obiect GUID sau indică cumva eșec. Dacă trimiteți un nul JSON pentru a indica un ghid inexistent, vor verifica, de asemenea, dacă datele JSON conțin o valoare NSNull (). Asta presupunând că dezvoltatorul nu este complet incompetent. În plus, în funcție de preferințele lor, vor folosi fie GUID-uri opționale și vor verifica zero, fie GUID-uri non-opționale și vor avea o proprietate care verifică dacă un GUID este zero. Asta „este complet independent de ceea ce faceți.

În mod serios, puteți face ceea ce vă place (păstrați-l constant). Orice dezvoltator care nu este complet incompetent va fi bine.„ Crearea unei metode de analiză ”este ceva care se face foarte ușor. Ca dezvoltator iOS, acest lucru nu merită nici măcar discutat. Documentați ce trimiteți. Voi crea o metodă de analiză mai rapidă decât ar lua discuția noastră.

Comentarii

  • Da, sunt de acord cu dvs., controlez ce ar trebui făcut, Și știu că dezvoltatorul iOS va deschide un parser într-o clipă. Dar acesta este răspunsul corect? Speram la un răspuns mai solid .. dar poate există ´ t one. Voi ´ voi lăsa acest marinat pentru puțin timp și apoi îți voi oferi răspunsul că nu vine nimic mai bun.

Răspuns

Deoarece în .NET Guid este un tip de valoare, nu i se poate atribui valoarea nulă.

Dacă trebuie să stocăm valori nule în tipuri de valori soluția normală este să utilizați Nullable sau, pe scurt, să utilizați sintaxa? ca în Guid? int? long? etc.

Acest lucru va funcționa și cu serializatoarele standard, astfel încât valoarea va lipsi sau va avea literalul valoare nulă.

Comentarii

  • Esben, acest răspuns nu se adresează OP . Vă rugăm să aruncați o privire mai profundă înainte de a răspunde.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *