Van egy .net api háttérképem a mobilalkalmazásokhoz, és felmerült a kérdés (az iOS fejlesztővel folytatott beszélgetés során), ha JSON válasz adott egy üres GUID vissza kell térnie:
- 00000000-0000-0000-0000-00000000000000
- vagy null (a return típus nullable Guid típusával (Guid?)
Ha az első, akkor a mobil fejlesztőnek létre kell hoznia egy elemzési módszert, és nem a szokásos általános nullellenőrzési funkcióját kell használnia.
A C # mezőben ezt tenné: 2c1902be39 “>
De az iOS fejlesztője egy elemzési módszer létrehozásáról beszél (gondolom, ne építse be).
De én nem talál megbeszélést arról, hogy mi tekinthető “bevált gyakorlatnak” , vagy arról, hogy a natív alkalmazások hogyan foglalkoznak az üres / null Guiddal.
Tudom mit szeretek csinálni, de mit gondolsz, mit kellene tennem?
Hozzászólások
- Először is, mit csinál ‘, ha ‘ s nem egy üres GUID? Miért van szükség elemzési módszerre az üres, de nem üres GUID-hez? ‘ nem végezhet egyenlőség-ellenőrzést a ” 00000000-0000-0000-0000-000000000000 ?
- Az Üres útmutató eltér a nem létező útmutatótól. A .Net-en az üres konvenciója mindenképpen 00 … 00, de nem biztos, hogy ezt a konvenciót szeretné nyilvános API-ra szivárogtatni, amelyet ‘ más platformok használnak. Ahelyett, hogy megpróbálná meghatározni, mi ‘ s üres és mi ‘ nem, meg kell határoznia a Guid és annak hiányát. , használjon olyan konvenciót, amely minden platformon (web, IOS, Android stb.) Könnyű lenne, és protokollként őrizze meg.
- @Machado is .net konvenció? ” A ” nil ” UUID, különleges eset, az UUID ” hu.wikipedia.org/wiki/Universally_unique_identifier#Standards
- gyanítom, hogy a .Net csak Guiddal rendelkezik .Üres, mert az 1.0-s kiadásban nem voltak generikusok és nem voltak Nullable < T >, így az Empty stand-inként jelentett nullat, mivel a Guid értéktípus, de valójában nem érvényes guid érték. A kódbázisban, amelyben ma dolgozom, valamilyen oknál fogva mindenhol vannak Guid-ok, és az Üres és a null semantikailag ugyanazt jelenti. Elég bosszantó, és én ‘ azt tettem, hogy a Guid nem kell folyamatosan ellenőriznie mindkét esetet, de ez ‘ csak azért van, mert ‘ csak most szabadulhat meg Guidtól .Üres.
- Itt ‘ fontos különbség van egy ” üres ” konstans és null: az egyik NRE-ket okoz, a másik pedig ‘ t nyer. Mindkettőt ellenőrizni és kezelni kell, ezért szedje a mérget. Gyorsan vagy némán bukni szeretne?
Válasz
Az “üres” útmutató továbbra is érvényes útmutató , ezért annak elemzése nem igényel különösebb logikát.
A kérdés az, hogy miért használja egyáltalán? Számomra tévedésnek tűnik, ha egy adott útmutatásnak különleges jelentést tulajdonítok, így varázslat lesz belőle. szám.
Kicsit olyan, mintha azt mondanám, hogy visszaadok egy int azonosítót, de ha negatív, akkor hibakódot ad. Ne tegye!
. Ennek oka, hogy a függvény minden hívása során a felhasználónak emlékeznie kell a negatív visszatérési érték ellenőrzésére. Ha elfelejtik, katasztrófa következik be.
Hasonlóképpen, ha a guid.empty-nek különleges jelentést rendel, mindenkinek, aki felhívja az API-t, minden hívás után külön ellenőrzést kell írnia.
Ez ” jobb, ha nullát adunk vissza (adott esetben), vagy kivételt vetünk (HTTP hibakódon keresztül, feltételezve a REST szolgáltatást).
Megjegyzések
- mert egy nap lesz egy figyelmeztető kódod, vagy egy 504.2-es hiba, és nem tudod negatív egész számba vagy negatív id-be szorítani, és az egész rendszer összeomlik
- egy kicsit oldala kérdés valóban. A guid.empty (mint bármely más speciális útmutató) soha nem fog generálódni
- OP didn ‘ t semmilyen különleges jelentést nem tulajdonít 00-ig, a .Net csapat tette. A kérdés az, hogy hagyjuk-e szivárogni ezt az absztrakciót.
- @RubberDuck: a nulla UUID valójában az RFC része, amely leírja az UUID-t már ” kiszivárgott “. ref tools.ietf.org/html/rfc4122#section-4.1.7
- Nos, @Newtopian, ha ‘ része az RFC-nek, akkor teljesen elfogadhatónak találom, ha API válaszként adjuk vissza. Ha a kliens ‘ nyelv / könyvtár nem ‘ nem határoz meg állandó értéket hozzá, akkor A div> s elég egyszerű ahhoz, hogy létrehozzon és megfelelően kezelje.
Válasz
iOS fejlesztő vagyok, és Fogalmam sincs, miért gondolja a srácod, hogy létre kell hoznia egy “elemzési módszert”. Mindössze annyit kell tennie, hogy UUID(uuidString: valueFromServer) t csináljon. A varázslat UUID-jét egyszerűen létrehozhatja:
extension UUID { static var zero: UUID { return UUID(uuidString: "00000000-0000-0000-0000-000000000000")! } } Ezután bármely GUID-t össze tudja hasonlítani ezzel a varázslatos GUID-del.
Ez azt jelenti, hogy a kiszolgálóról származó összes értéknél a frontend fejlesztőjének először ellenőrizze, hogy van-e az érték, majd ellenőrizze, hogy jól van-e formázva (megfelelő típusú.) Ha mágikus értéket ad vissza, akkor is ellenőriznie kell, hogy az a helyesen beírt érték varázslat. A mágikus érték felvételével arra kényszeríted, hogy tegyen további ellenőrzést.
Frontend fejlesztőként azt kell kérdeznem: Miért kényszerítesz arra, hogy növeljem az alkalmazásom összetettségét?
Ha meg tud adni egy érvet, miszerint a kezelőfelületnek a hiányzó GUID-t másként kell kezelnie, mint a mágikus GUID-t, akkor meg kell adnia egy argumentumot annak visszaadására. Ellenkező esetben felesleges bonyolultságot ad a frontend alkalmazáshoz.
(Kiegészítés a @RubberDuck megjegyzésére válaszul.)
Itt van a dolog. A JSON szabványnak egyetlen módja van a nullértékek kezelésére, a GUID szabványnak pedig más módja a nullértékek kezelésére. Mivel egy GUID-t a JSON-on keresztül küld, ez utóbbi a átfogó probléma (mivel a GUID-t JSON-ba csomagolják), ez a szabvány, amelynek meg kell felelnie. . Mert még akkor is, ha úgy dönt, hogy nullás GUID-t küld, és valóban nullákkal teli GUID-t küld, a kezelőfelületnek még mindig ellenőriznie kell a JSON null értékét.
Ne kényszerítse a kezelőfelületet a null két különböző fogalmának kezelésére.
Kommentárok
- Mivel ‘ az RFC része? tools.ietf.org/html/rfc4122#section-4.1.7
- Ó, a véletlenszerű összetettség öröme. Bonyolultabbá kell tennem az alkalmazásomat, mert néhány RFC-bizottság olyan döntést hozott, amelynek nincs értelme a rendszeremnek.
- Nem, az alkalmazását összetettebbé teszi, így hogy a rendszere rugalmasabbá válik egy jól definiált szabvány elfogadásával. Továbbá, ha libjei nem ‘ nem támogatják natívan a szabványt, akkor egy bűzt emel, és felkéri őket, hogy javítsák ki az upstream felé.
- Vagy megváltoztatja a szabványt, mert ‘ buta. A varázsértékek a legrosszabbak. Mi a következő, egy RFC, amely azt mondja, hogy 0 int értéke 0, valójában NULL ?
Válasz
Tedd, amit szeretsz (ami a MacOS-t és az iOS-t illeti).
Az iOS vagy a MacOS fejlődik r ír egy elemzési módszert, amely ellenőrzi, hogy a JSON-adatok tartalmaznak-e egy karakterláncot, és GUID-objektummá alakítja-e, vagy valamilyen módon hibát jelez. Ha egy JSON null értéket küld egy nem létező útmutató megadására, akkor azt is ellenőrzi, hogy a JSON adatok tartalmaznak-e NSNull () értéket. Ez azt feltételezi, hogy a fejlesztő nem teljesen képtelen. Ezen túlmenően, preferenciájuktól függően, vagy választható GUID-eket használnak, és ellenőrzik, hogy nincsenek-e nullák, vagy nem opcionális GUID-eket, és rendelkeznek egy tulajdonsággal, amely ellenőrzi, hogy a GUID mind nulla-e. Ez teljesen független attól, amit csinál.
Olyan komolyan, megteheti, amit szeret (csak tartsa következetesnek). Bármely nem teljesen alkalmatlan fejlesztő rendben lesz. “Az elemzési módszer létrehozása” ami nagyon egyszerűen elvégezhető. Mint főleg iOS fejlesztő, ezt még nem is érdemes megbeszélni. Dokumentálja, amit küld. Gyorsabban létrehozok egy elemzési módszert, mint amire a megbeszélésünk tart.
Megjegyzések
- Igen, egyetértek veled, én irányítom a teendőket, és megteszem. És tudom, hogy az iOS fejlesztő egy pillanat alatt felkorbácsol egy elemzőt. De vajon ez a helyes válasz? Szilárdabb választ reméltem .. de lehet, hogy van ´ t egyet. Én ´ hagyom ezt a pácolást egy ideig, majd megadom a választ, semmi sem jobb.
Válasz
Mivel a .NET Guid egy értéktípus, nem rendelhető hozzá null érték.
Ha nullákat kell tárolnunk értéktípusokban a normális megoldás a Nullable használata, vagy rövidítésként a? szintaxis használata, mint a Guidban? int? long? stb.
Ez a szokásos sorosítókkal is együtt fog működni, így az érték vagy hiányzik, vagy a szó szerinti null érték.
Megjegyzések
- Esben, ez a válasz nem foglalkozik az OP ‘ kérdés. Kérjük, mélyebben vizsgálja meg, mielőtt válaszolna.