Mam zaplecze .net API dla aplikacji mobilnych i pojawiło się pytanie (w rozmowie z programistą iOS), czy odpowiedź JSON dla pusty identyfikator GUID powinien zwrócić:

  • 00000000-0000-0000-0000-000000000000
  • lub null (ustawiając zwracany typ zerowy Guid type (Guid?)

Jeśli pierwszy z nich, programista aplikacji mobilnych musi stworzyć metodę parsowania dla tego i nie używać swojej zwykłej ogólnej funkcji sprawdzania wartości null.

W C # po prostu zrobiłbyś 

if (guid == Guid.Empty)

Ale programista iOS mówi o tworzeniu metody analizowania (więc chyba nie jest wbudowana).

Ale ja nie mogę znaleźć żadnej dyskusji na temat tego, co jest uważane za „najlepszą praktykę” , ani nawet tego, jak aplikacje natywne radzą sobie z pustymi / zerowymi identyfikatorami Guid.

Wiem co lubię robić, ale jak myślisz, co powinienem zrobić?

Komentarze

  • Po pierwsze, co ' zrobi, jeśli ' s nie pusty identyfikator GUID? Ponadto, dlaczego potrzebuje metody analizy dla pustego, ale nie niepustego identyfikatora GUID? Czy ' może po prostu sprawdzić równość w odniesieniu do ciągu ” 00000000-0000-0000-0000-000000000000 „?
  • Pusty Guid różni się od nieistniejącego Guid. Z całą pewnością konwencja pustego w .Net to 00 …. 00, ale możesz nie chcieć przeciekać tej konwencji do publicznego interfejsu API, który ' jest używany przez inne platformy. Zamiast próbować definiować, co ' jest puste, a czego ' nie, musisz zdefiniować znaczenie posiadania i braku Guid , użyj konwencji, która byłaby łatwa dla wszystkich platform (WWW, IOS, Android itp.) i zachowaj ją jako protokół.
  • @Machado, czy to jest konwencja .net? ” ” nil ” UUID, przypadek specjalny, to UUID ” en.wikipedia.org/wiki/Universally_unique_identifier#Standards
  • Podejrzewam .Net ma tylko Guid .Empty, ponieważ w wersji 1.0 nie było typów ogólnych ani dopuszczalnych wartości Nullable < T >, więc Empty stało się zastępczą wartością null, ponieważ Guid jest typem wartości, ale w rzeczywistości nie jest prawidłową wartością guid. W bazie kodu, w której dzisiaj pracuję, z jakiegoś powodu wszędzie są Guidy, a zarówno puste, jak i null semantycznie oznaczają to samo. Jest to dość denerwujące i ' sprawiłem, że Guid ' nie dopuszcza wartości null, więc nie ' nie muszę ciągle sprawdzać obu przypadków, ale to ' jest tylko dlatego, że ' jest teraz sposobem na pozbycie się Guid .Empty.
  • Istnieje ' różnica między ” pustym ” stała i zerowa: jedna spowoduje wystąpienie NRE, a druga wygra ' t. Oba muszą być sprawdzone i obsługiwane, więc wybierz swoją truciznę. Chcesz szybko zawieść lub po cichu zawieść?

Odpowiedź

„Pusty” identyfikator guid jest nadal prawidłowym identyfikatorem guid , więc jego analiza nie powinna wymagać żadnej dodatkowej logiki.

Pytanie brzmi, dlaczego w ogóle go używasz? Wydaje mi się, że błędem jest przypisywanie specjalnego znaczenia konkretnemu przewodnikowi, czyniąc go magicznym

To trochę tak, jakby powiedzieć, że zwrócę identyfikator int, ale jeśli jest ujemny, to jest to kod błędu. Nie rób tego!

.. Powodem jest to, że przy każdym wywołaniu funkcji użytkownik będzie musiał pamiętać o sprawdzeniu ujemnej wartości zwracanej. Jeśli zapomną, nastąpi katastrofa.

Podobnie, jeśli nadasz guid.empty specjalne znaczenie, każdy, kto wywoła Twoje API, będzie musiał napisać specjalny czek po każdym wywołaniu.

To ” lepiej jest zwrócić wartość null (jeśli to konieczne) lub zgłosić wyjątek (za pośrednictwem kodu błędu HTTP, zakładając usługę REST).

Komentarze

  • ponieważ pewnego dnia będziesz miał kod ostrzegawczy lub błąd 504.2 i nie będziesz w stanie wcisnąć go do ujemnej liczby całkowitej lub ujemnego identyfikatora i cały system się rozpadnie
  • to trochę z boku problem naprawdę. guid.empty (jak każdy inny konkretny guid) nigdy nie zostanie wygenerowany
  • OP nie ' t nie przypisuje żadnego specjalnego znaczenia do 00..00, zespół .Net tak zrobił. Pytanie brzmi, czy pozwolić na wyciek tej abstrakcji.
  • @RubberDuck: zerowy UUID jest w rzeczywistości częścią RFC opisującego UUID, więc abstrakcja ma już ” wyciekło „. ref tools.ietf.org/html/rfc4122#section-4.1.7
  • Cóż, @Newtopian, jeśli jest ' częścią specyfikacji RFC, to uważam, że zwrócenie go w odpowiedzi API jest całkowicie dopuszczalne. Jeśli klient ' język / biblioteka nie ' nie definiuje dla niego stałej, ' jest na tyle proste, że można je utworzyć i odpowiednio obsługiwać.

Odpowiedź

Jestem programistą iOS i Nie mam pojęcia, dlaczego twój facet myśli, że musi stworzyć „metodę analizy”. UUID(uuidString: valueFromServer) to wszystko, co musi zrobić. Może stworzyć Twój magiczny UUID po prostu: 

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

Następnie może porównać dowolny identyfikator GUID z tym magicznym identyfikatorem GUID.

To powiedziawszy, dla wszystkich wartości pochodzących z serwera, programista frontendu musi najpierw sprawdź, czy wartość tam jest, a następnie sprawdź, czy jest poprawnie sformułowana (odpowiedniego typu). Jeśli zwracasz wartość magiczną, musi także sprawdzić, czy poprawnie wpisana wartość jest magiczna. Włączając magiczną wartość, zmuszasz go do dodatkowego, jeśli to zrobisz.

Jako programista frontendu muszę zapytać: z jakiego powodu zmuszasz mnie do zwiększenia złożoności mojej aplikacji?

Jeśli możesz argumentować, że frontend powinien traktować brakujący identyfikator GUID inaczej niż magiczny identyfikator GUID, to masz argument, aby go zwrócić. W przeciwnym razie dodasz niepotrzebną złożoność do aplikacji frontendowej.

(Dodanie w odpowiedzi na komentarz @RubberDuck).

Oto rzecz. Standard JSON ma jeden sposób postępowania z wartościami null, a standard GUID ma inny sposób postępowania z wartościami null. Ponieważ wysyłasz GUID przez JSON , to drugie jest nadrzędnym problemem (ponieważ GUID jest zawijany w JSON), jest to standard, z którym powinieneś być zgodny. Ponieważ nawet jeśli zdecydujesz się wysłać pusty identyfikator GUID, wysyłając identyfikator GUID pełen zer, frontend nadal musi sprawdzać, czy wartość JSON ma wartość null.

Nie zmuszaj front-endu do radzenia sobie z dwoma różnymi koncepcjami null.

Komentarze

  • Ponieważ ' s częścią RFC? tools.ietf.org/html/rfc4122#section-4.1.7
  • Och, radość z przypadkowej złożoności. Muszę uczynić moją aplikację bardziej złożoną, ponieważ jakiś komitet RFC dokonał wyboru, który nie ma sensu w moim systemie.
  • Nie, sprawiasz, że aplikacja jest bardziej złożona, więc że twój system staje się bardziej elastyczny, akceptując dobrze zdefiniowany standard. Ponadto, jeśli twoje biblioteki nie ' natywnie obsługują standard, wywołujesz smród i prosisz ich o naprawienie tego standardu.
  • Albo zmienisz standard, ponieważ ' jest głupi. Magiczne wartości są najgorsze. Co dalej, dokument RFC mówiący, że wartość int równa 0 jest w rzeczywistości NULL ?

Odpowiedź

Rób, co lubisz (jeśli chodzi o MacOS i iOS).

Powstaje iOS lub MacOS r zapisze metodę analizowania, która sprawdza, czy dane JSON zawierają ciąg i zamieni go na obiekt GUID lub w jakiś sposób wskaże błąd. Jeśli wyślesz wartość null JSON, aby wskazać nieistniejący identyfikator guid, sprawdzą również, czy dane JSON zawierają wartość NSNull (). Zakłada się, że programista nie jest całkowicie niekompetentny. Ponadto, w zależności od swoich preferencji, będą albo używać opcjonalnych identyfikatorów GUID i sprawdzać, czy nie ma żadnych, albo nieopcjonalnych identyfikatorów GUID i będą mieć właściwość, która sprawdza, czy identyfikator GUID jest zerowy. To jest całkowicie niezależne od tego, co robisz.

Tak poważnie, możesz robić, co chcesz (po prostu zachowaj spójność). Każdy niezupełnie niekompetentny programista będzie w porządku. „Tworzenie metody analizowania” to coś, co robi się bardzo łatwo. Ponieważ jest to większość programistów iOS, nie jest to nawet warte dyskusji. Dokumentuj, co wysyłasz. Utworzę metodę analizowania szybciej niż nasza dyskusja.

Komentarze

  • Tak, zgadzam się z tobą, kontroluję, co należy zrobić, i tak zrobię. Wiem, że programista iOS błyskawicznie uruchomi parser. Ale czy to jest właściwa odpowiedź? Liczyłem na bardziej solidną odpowiedź … ale może jest ´ t one. ´ Pozwolę temu marynować przez chwilę, a potem udzielę odpowiedzi, nic lepszego nie nadejdzie.

Odpowiedź

Ponieważ w .NET Guid jest typem wartości, nie można mu przypisać wartości null.

Jeśli musimy przechowywać wartości null w typach wartości normalnym rozwiązaniem jest użycie wartości Nullable lub jako skrótu użycie? składni, takiej jak w Guid? int? long? itd.

Będzie to również działać ze standardowymi serializatorami, więc wartość będzie albo brakować, albo będzie miała literał wartość null.

Komentarze

  • Esben, ta odpowiedź nie dotyczy OP ' pytanie. Przed udzieleniem odpowiedzi przyjrzyj się jej dokładniej.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *