Minulla on .net api -taustapuhelin mobiilisovelluksille ja kysymys tuli esiin (keskustellessa iOS-kehittäjän kanssa), jos JSON-vastaus tyhjän GUID-tunnuksen pitäisi palata:
- 00000000-0000-0000-0000-00000000000000
- tai null (antamalla palautustyyppi tyhjäksi Guid-tyyppi (Guid?)
Jos ensimmäinen, mobiilikehittäjän on luotava siihen jäsennysmenetelmä eikä hänen säännöllistä yleistä nollaustoimintoa.
C #: ssä teet vain
if (guid == Guid.Empty) Mutta iOS-kehittäjä puhuu jäsentämismenetelmän luomisesta (joten älä luule sisään).
Mutta minä ei löydy keskustelua siitä, mitä pidetään ”parhaana käytäntönä” tai siitä, kuinka natiivisovellukset käsittelevät tyhjiä / tyhjiä oppaita.
Tiedän mitä haluan tehdä, mutta mitä luulet minun tekevän?
Kommentit
- Ensinnäkin, mitä ’ tekee, jos se ’ s ei tyhjä GUID? Miksi hän tarvitsee jäsentämismenetelmän tyhjälle mutta ei tyhjälle GUID: lle? Voiko ’ t vain tehdä tasa-arvotarkistuksen merkkijonoa ” 00000000-0000-0000-0000-000000000000 ”?
- Tyhjä ohje on erilainen kuin olematon opas. Kaiken kaikkiaan .Net: n tyhjän käytäntö on 00 … 00, mutta et ehkä halua vuotaa tätä käytäntöä julkiselle sovellusliittymälle, jota ’ käyttää muilla alustoilla. Sen sijaan, että yrität määritellä mitä ’ on tyhjää ja mikä ’ ei, sinun on määriteltävä merkitys, jolla sinulla on opas ja ei. , käytä sopimusta, joka olisi helppoa kaikille alustoille (verkko, IOS, Android jne.) ja pidä se protokollana.
- @Machado hyvin, onko se .net-käytäntö? ” ” nil ” UUID, erikoistapaus, on UUID ” fi.wikipedia.org/wiki/Universally_unique_identifier#Standards
- epäilen, että .Netillä on vain opas .Tyhjä, koska versiossa 1.0 ei ollut geneerisiä aineita eikä Nullable < T >, joten Tyhjästä tuli stand in tarkoittaa null, koska Guid on arvotyyppi, mutta se ei oikeastaan ole kelvollinen guid-arvo. Koodipohjassa, jossa työskentelen tänään, on jostain syystä Guid? It kaikkialla, ja sekä Tyhjä että tyhjä tarkoittavat semanttisesti samaa. Se on melko ärsyttävää, ja olen ’ tehnyt Guid ’ -soittimista mitätöimättömiä, joten en ’ ei tarvitse tarkistaa molempia tapauksia, mutta ’ s vain siksi, että ’ on nyt tapa päästä eroon Guidista .Tyhjä.
- Siellä ’ on tärkeä ero ” tyhjän ” vakio ja tyhjä: toinen aiheuttaa NRE: itä ja toinen voitti ’ t. Molemmat on tarkistettava ja käsiteltävä, joten poimi myrkkysi. Haluatko epäonnistua nopeasti tai epäonnistua hiljaa?
Vastaa
”Tyhjä” opas on edelleen kelvollinen opas , joten sen jäsentäminen ei saisi edellyttää ylimääräistä logiikkaa.
Kysymys on, miksi käytät sitä ollenkaan? Minusta näyttää olevan virhe antaa erityinen merkitys tietylle oppaalle, mikä tekee siitä maagisen numero.
Se on vähän kuin sanoisin, että palautan int id: n, mutta jos se on negatiivinen, se on virhekoodi. Älä tee sitä!
Syy siihen, että käyttäjän on jokaisessa toiminnon kutsussa muistettava tarkistamaan negatiivinen paluuarvo. Jos he unohtavat, tapahtuu katastrofi.
Vastaavasti, jos määrität guid.empty: lle erityisen merkityksen, jokaisen, joka kutsuu sovellusliittymääsi, on kirjoitettava erityinen tarkistus jokaisen puhelun jälkeen.
Se ” on parempi palauttaa null (tarvittaessa) tai heittää poikkeus (HTTP-virhekoodin avulla, olettaen REST-palvelun).
Kommentit
- koska jonain päivänä sinulla on varoituskoodi tai virhe 504.2, etkä pysty puristamaan sitä negatiiviseksi kokonaisluvuksi tai negatiiviseksi id: ksi, ja koko järjestelmä murenee
- sen hieman puoli kysymystä oikeastaan. guid.empty-ohjelmaa (kuten mitä tahansa muuta erityistä ohjetta) ei koskaan luoda
- OP didn ’ t anneta mitään erityistä merkitystä – 00..00, .Net-tiimi teki. Kysymys on, annetaanko tämän abstraktion vuotaa vai ei.
- @RubberDuck: nolla UUID on itse asiassa osa RFC: tä, joka kuvaa UUID: tä, joten abstraktio on jo ” vuotanut ”. ref tools.ietf.org/html/rfc4122#section-4.1.7
- No, @Newtopian, jos se ’ on osa RFC: tä, minusta on täysin hyväksyttävää palauttaa se API-vasteena. Jos asiakkaan ’ kieli / kirjasto ei määritä ’ t vakiota sille, se ’ s on riittävän yksinkertainen sellaisen luomiseen ja asianmukaiseen käsittelyyn.
Vastaa
Olen iOS-kehittäjä ja Minulla ei ole aavistustakaan, miksi kaverisi mielestä hänen täytyy luoda ”jäsentämismenetelmä”. UUID(uuidString: valueFromServer) on kaikki mitä hänen on tehtävä. Hän voi luoda maagisen UUID-tunnuksesi yksinkertaisesti:
extension UUID { static var zero: UUID { return UUID(uuidString: "00000000-0000-0000-0000-000000000000")! } } Sitten hän voi verrata mitä tahansa GUID-tunnusta tähän maagiseen GUID-tunnukseen.
Tästä huolimatta käyttöliittymäkehittäjän on ensin määritettävä kaikki palvelimelta tulevat arvot. tarkista onko arvo olemassa ja tarkista sitten onko se hyvin muodostettu (oikean tyyppinen.) Jos palautat maagisen arvon, hänen on myös tarkistettava onko oikein kirjoitettu arvo on taikuutta. Lisäämällä taika-arvon pakotat hänet tekemään ylimääräisen tarkastuksen.
Frontend-kehittäjänä minun on kysyttävä: Mistä syystä pakotat minua lisäämään sovellukseni monimutkaisuutta?
Jos pystyt väittämään, että käyttöliittymän tulisi puuttuvaa GUID: tä kohdella eri tavalla kuin maaginen GUID, sinulla on argumentti sen palauttamiseksi. Muuten lisäät tarpeetonta monimutkaisuutta käyttöliittymäsovellukseen.
(Lisäys vastauksena @RubberDuck kommenttiin.)
Tässä on asia. JSON-standardilla on yksi tapa käsitellä nolla-arvoja ja GUID-standardilla on erilainen tapa käsitellä nolla-arvoja. Koska lähetät GUID-tunnuksen JSON: n kautta , jälkimmäinen on kattava huolenaihe (koska GUID on kääritty JSON: iin), se on standardi, jota sinun tulisi noudattaa. Koska vaikka päätät lähettää nollan GUID: n lähettämällä itse asiassa nollia sisältävän GUID: n, käyttöliittymän silti on tarkistettava JSON nolla.
Älä pakota käyttöliittymää käsittelemään kahta erilaista null-käsitettä.
Kommentit
- Koska se ’ RFC: n osa? tools.ietf.org/html/rfc4122#section-4.1.7
- Voi vahingossa tapahtuvan monimutkaisuuden ilot. Minun on tehtävä sovelluksestani monimutkaisempi, koska jotkut RFC-komiteat tekivät valinnan, jolla ei ole järkeä järjestelmässäni.
- Ei, teet sovelluksestasi monimutkaisemman että järjestelmästäsi tulee joustavampi hyväksymällä hyvin määritelty standardi. Jos libssi eivät ’ tue luonnostaan standardia, nostat haisun ja pyydät heitä korjaamaan sen ylävirtaan.
- Tai saat standardin muutettua, koska se ’ on tyhmä. Maagiset arvot ovat pahin. Mitä seuraavaksi, RFC, joka sanoo int-arvon 0, on itse asiassa NULL ?
Vastaa
Tee mitä haluat (MacOS: n ja iOS: n osalta).
iOS tai MacOS kehittyvät r kirjoittaa jäsennysmenetelmän, joka tarkistaa, sisältävätkö JSON-tietosi merkkijonon, ja muuttaa siitä GUID-objektin tai jotenkin vioittavan. Jos lähetät JSON-nollan ilmoittamaan olematon opas, he tarkistavat myös, sisältävätkö JSON-tiedot NSNull () -arvon. Oletetaan, että kehittäjä ei ole täysin epäpätevä. Lisäksi he käyttävät mieltymyksistään riippuen joko valinnaisia GUID-tunnuksia ja tarkistavat nollan tai ei-valinnaiset GUID-tunnukset ja niillä on ominaisuus, joka tarkistaa, onko GUID kaikki nollat. Se on täysin riippumaton siitä, mitä teet.
Joten vakavasti, voit tehdä mitä haluat (pidä se johdonmukaisena). Jokainen ei täysin epäpätevä kehittäjä on hieno. ”Jäsennysmenetelmän luominen” on jotain, joka tehdään hyvin helposti. Koska enimmäkseen iOS-kehittäjä, tästä ei edes kannata keskustella. Dokumentoi, mitä lähetät. Luon jäsennysmenetelmän nopeammin kuin keskustelumme vie.
Kommentit
- Kyllä, olen kanssasi samaa mieltä, hallitsen mitä pitäisi tehdä, Ja minä tiedän. Ja tiedän, että iOS-kehittäjä piiskaa jäsentimen hetkessä. Mutta onko tämä oikea vastaus? Toivoin vakaampaa vastausta .. mutta ehkä ´ t yksi. I ´ Annan tämän marinoitua vähän aikaa ja annan sitten vastauksen, mitään parempaa ei tule.
Vastaa
Koska .NET Guid on arvotyyppi, sille ei voida antaa arvoa null.
Jos meidän on tallennettava nollia arvotyyppeihin normaali ratkaisu on käyttää Nullable tai lyhenteenä käyttää? syntaksia kuten Guidissa? int? long? jne.
Tämä toimii myös tavallisten serializerien kanssa, joten arvo puuttuu tai se on kirjaimellisesti nolla-arvo.
Kommentit
- Esben, tämä vastaus ei koske OP ’ kysymys. Tutki asiaa tarkemmin ennen vastaamista.