Mám back-end rozhraní API pro mobilní aplikace a přišla otázka (v konverzaci s vývojářem iOS), pokud odpověď JSON pro prázdný identifikátor GUID by se měl vrátit:

  • 00000000-0000-0000-0000-000000000000
  • nebo null (tím, že bude mít návratový typ s možnou hodnotou Null typ Guid (Guid?)

Je-li první, mobilní vývojář pro to musí vytvořit metodu syntézy a nepoužívat svou běžnou generickou funkci kontroly nuly.

V C # byste to udělali 

if (guid == Guid.Empty)

Vývojář systému iOS však mluví o vytvoření metody analýzy (takže myslím, že to není zabudováno).

Ale já nenajdu žádnou diskusi o tom, co je považováno za „osvědčený postup“ , ani o tom, jak nativní aplikace jednají s prázdnými / nulovými Guid „.

Vím co rád dělám, ale co si myslíte, že bych měl udělat?

Komentáře

  • Za prvé, co ‚ dělá, pokud ‚ s ne prázdný GUID? Proč také potřebuje metodu analýzy pro prázdný, ale ne neprázdný GUID? Nemůže ‚ pouze provést kontrolu rovnosti proti řetězci “ 00000000-0000-0000-0000-000000000000 „?
  • Prázdný průvodce se liší od neexistujícího průvodce. V každém případě je konvence empty on .Net 00 …. 00, ale možná nebudete chtít tuto konvenci propustit na veřejné API, které ‚ používá jiné platformy. Místo toho, abyste se pokusili definovat, co je ‚ prázdné a co ‚ není, musíte definovat význam mít a nemít Guid , použijte konvenci, která by byla snadná pro všechny platformy (web, IOS, Android atd.) a udržujte ji jako protokol.
  • @Machado, je to konvence .net? “ “ nil “ UUID, zvláštní případ, je UUID “ en.wikipedia.org/wiki/Universally_unique_identifier#Standards
  • Mám podezření, že síť má pouze Guid . Prázdný, protože ve verzi 1.0 nebyly žádné generické a žádné Nullable < T >, takže Empty se stal standartem ve smyslu null, protože Guid je typ hodnoty, ale ve skutečnosti to není platná hodnota guid. V kódové základně, ve které dnes pracuji, jsou z nějakého důvodu všude Guids, a Empty i null sémanticky znamenají totéž. Je to docela nepříjemné a já ‚ jsem způsobil, že Guid ‚ je nenulový, takže ‚ nemusíme stále kontrolovat oba případy, ale ‚ to jen proto, že ‚ nyní existuje způsob, jak se zbavit Guidu . Prázdný.
  • Mezi “ prázdným “

důležitý rozdíl. konstantní a null: jeden způsobí NRE a druhý nebude ‚ t. Oba je třeba zkontrolovat a zacházet s nimi, takže si vyberte svůj jed. Chcete selhat rychle nebo selhat tiše?

Odpovědět

„Prázdný“ guid je stále platný guid , takže analýza by neměla vyžadovat žádnou další logiku.

Otázkou je, proč ji vůbec používáte? Zdá se mi jako chyba přiřadit zvláštní význam konkrétnímu průvodci, což z něj dělá kouzlo číslo.

Je to trochu jako říkat „Vrátím ID int, ale pokud je záporné, jedná se o chybový kód. Nedělejte to!

Důvodem je to, že při každém volání vaší funkce bude uživatel muset pamatovat na kontrolu záporné návratové hodnoty. Pokud zapomenou, dojde ke katastrofě.

Podobně pokud přiřadíte guid.empty zvláštní význam, každý, kdo volá vaše API, musí po každém volání napsat speciální kontrolu.

To “ je lepší vrátit null (je-li to vhodné) nebo vyvolat výjimku (pomocí chybového kódu HTTP za předpokladu služby REST).

Komentáře

  • protože jednoho dne budete mít varovný kód nebo chybu 504.2 a nebudete ji moci vtesnat do záporného celého čísla nebo záporného ID a celý systém se rozpadne
  • je to trochu stranou problém opravdu. guid.empty (stejně jako jakýkoli jiný konkrétní guid) nebude nikdy vygenerován
  • OP nepřidělil ‚ t žádný zvláštní význam do 00..00 tým .Net. Otázkou je, zda nechat uniknout tuto abstrakci.
  • @RubberDuck: nulový UUID je ve skutečnosti součástí RFC, který popisuje UUID, takže abstrakce má již “ unikly „. ref tools.ietf.org/html/rfc4122#section-4.1.7
  • No @Newtopian, pokud je to ‚ součástí RFC, považuji za zcela přijatelné jej vrátit v odpovědi API. Pokud klient ‚ s jazyk / knihovna nedefinuje ‚ pro něj konstantu, ‚ je natolik jednoduchý, že ho vytvořím a vhodně s ním zacházím.

Odpovědět

Jsem vývojář pro iOS a Netuším, proč si váš člověk myslí, že potřebuje vytvořit „metodu rozebrání.“ UUID(uuidString: valueFromServer) je vše, co musí udělat. Může vytvořit váš magický UUID jednoduše: 

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

Poté může porovnat libovolný identifikátor GUID s tímto magickým identifikátorem GUID.

To znamená, že u všech hodnot, které pocházejí ze serveru, musí vývojář front-endu zkontrolujte, zda je tam hodnota, pak zkontrolujte, zda je dobře tvarovaná (správného typu). Pokud vracíte magickou hodnotu, musí také zkontrolovat, zda správně napsaná hodnota je magická. Zahrnutím magické hodnoty ho nutíte, aby vytvořil další, pokud je zkontrolován.

Jako frontendový vývojář se musím zeptat: Z jakého důvodu mě nutíte, abych zvýšil složitost mé aplikace?

Pokud můžete uvést argument, že by frontend měl zacházet s chybějícím identifikátorem GUID jinak než s magickým identifikátorem GUID, máte argument pro jeho vrácení. V opačném případě přidáváte aplikaci frontend zbytečnou složitost.

(Doplnění v reakci na komentář @RubberDuck.)

Tady je věc. Standard JSON má jeden způsob řešení nulových hodnot a standard GUID má jiný způsob řešení nulových hodnot. Jelikož odesíláte identifikátor GUID prostřednictvím JSON , jedná se o zastřešující problém (protože identifikátor GUID je zabalen do formátu JSON), jedná se o standard, kterému byste se měli přizpůsobit. . Protože i když se rozhodnete poslat nulový identifikátor GUID tak, že skutečně odešlete identifikátor GUID plný nul, rozhraní stále musí zkontrolovat, zda je JSON null.

Nevynucujte rozhraní, aby se zabývalo dvěma různými koncepty null.

Komentáře

  • Protože to ‚ část RFC? tools.ietf.org/html/rfc4122#section-4.1.7
  • Ach radosti z náhodné složitosti. Musím svou aplikaci složitější, protože nějaký výbor RFC učinil nějakou volbu, která v mém systému nedává smysl.
  • Ne, svou aplikaci děláte složitější, že se váš systém stane flexibilnějším přijetím dobře definovaného standardu. Také pokud vaše libs standard

nativně nepodporují, zvednete smrad a požádáte je, aby jej opravili proti proudu.

  • Nebo získáte změnu standardu, protože je ‚ hloupý. Kouzelné hodnoty jsou nejhorší. Co dál, RFC, který říká, že hodnota int je 0, je ve skutečnosti NULL ?

    • Odpověď

    Dělejte, co chcete (pokud jde o MacOS a iOS).

    Vývoj iOS nebo MacOS r zapíše metodu analýzy, která zkontroluje, zda vaše data JSON obsahují řetězec, a promění je na objekt GUID nebo nějakým způsobem naznačují selhání. Pokud pošlete null JSON k označení neexistujícího guid, zkontrolují také, zda data JSON obsahují hodnotu NSNull (). To za předpokladu, že vývojář není zcela nekompetentní. Kromě toho v závislosti na svých preferencích buď použijí volitelné identifikátory GUID a zkontrolují nula, nebo nepovinné identifikátory GUID a budou mít vlastnost, která zkontroluje, zda je identifikátor GUID nulový. To je zcela nezávislé na tom, co děláte.

    Takže vážně, můžete dělat, co se vám líbí (jen to udržujte konzistentní). Jakýkoli ne zcela nekompetentní vývojář bude v pořádku. „Vytvoření metody analýzy“ je něco, co se děje velmi snadno. Jako většinou vývojář iOS, to ani nestojí za diskusi. Zdokumentujte, co posíláte. „Metodu analýzy vytvořím rychleji, než by naše diskuse zabrala.

    Komentáře

    • Ano, souhlasím s vámi, mám kontrolu nad tím, co by mělo být provedeno, a já ano. A vím, že vývojář iOS rychle vybije analyzátor. Ale je to správná odpověď? Doufal jsem v solidnější odpověď .. ale možná existuje ´ t one. I ´ nechám to na chvíli marinovat a pak ti dám odpověď, nic lepšího nepřijde.

    Odpověď

    Protože v .NET Guid je typ hodnoty, nelze mu přiřadit hodnotu null.

    Pokud potřebujeme ukládat hodnoty null v typech hodnot běžným řešením je použít Nullable nebo jako zkratku použít? syntaxi jako v Guid? int? long? atd.

    Toto bude fungovat také se standardními serializátory, takže hodnota bude buď chybět, nebo bude mít literál nulová hodnota.

    Komentáře

    • Esben, tato odpověď neřeší OP ‚ s otázkou. Než odpovíte, důkladně se na to podívejte.

    Napsat komentář

    Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *