Covable vs ObjectMapper

Foto autor: https://unsplash.com/photos/_rNVw54xZZg

Olen hiljuti katsetanud Swifti uut Covablei protokolli, et kaardistada kaugteenusest tõmmatud JSON Swift-mudeiobjektiks.

Natuke taustaks lisati Swift 4-sse Covable kui viis, mis võimaldab objektidel puhtalt teisendada väliseks esituseks ja sellest välja. Kodeeritav ise on vaid tavaline dekoodeeritava ja kodeeritava tüüp.

Selle postituse puhul keskendun ma dekodeeritavale osale, kuna see on mu huvitav JSON-i kaugesinduse konversioon.

Võrdlus

Olen varem ObjectMapperit palju kasutanud, kuid kuna Codable on nüüd Swifti sisse ehitatud, tahtsin neid kahte võrrelda. Funktsioonid, mida tahan võrrelda, on järgmised.

  • Valideerimine ️
  • Kohandatud transformatsioon (kohandatud tüüpideks kaardistamine, nt JSON-stringi kaardistamine regexiks)
  • Viga käsitsemisel

Andmed, mida hakkan parsima, on tõeline konfiguratsioon, mille toome BBC Sport rakenduse jaoks eemalt

See on üsna lihtne JSON-struktuur, kuid sellel on paar regulaaravaldist, kuna tahaksin, et mind kaardistataks NSR RegularExpressioni, mitte stringiga

ObjectMapper

Selle JSON-mudeli ObjectMapperiga kaardistamiseks vajalikud struktuurid on järgmised.

Kõik kujundid vastavad ImmvableMappable protokollile, mis tähendab, et nad vajavad konstruktorit, kes võtab kaardiobjekti ja viskab vea, kui kaardistamine nurjub.

Kinnitamine

Valideerimise teostamiseks võite kasutada valikulisi. Selles näites otsustasime, et rakendus saab ilma nende e-posti aadressideta toimida, nii et meilid on valikulised. map.values ​​("e-kirjad") kuvatakse tõrge, kui võtit pole või kui seda ei saa õigesti sisestada. Kas me proovime? selle vea jäädvustamiseks ja vea korral muutke see lihtsalt nulliks.

Kui otsustame, et konkreetne atribuut on vajalik, siis me ei märgista seda valikulisena ja lubame veal levida.

Üldiselt on valideerimine ImmvableMappable abil väga lihtne

Võib-olla olete märganud, et selle kõne map.value ("regex", kasutades: RegexTransformer ()) kaudu on edastatud mõni täiendav argument - kohandatud ümberkujundamine muudab stringi NSRegularExpressioniks, mis viib mu kenasti mu järgmisse punkti!

Kohandatud ümberkujundamine

ObjectMapper toetab kohandatud teisendusi karbist välja ja see on väga lihtne.

Siin rakendame lihtsalt protokolli TransformType ja sellega seotud meetodit transforFromJSON. See võtab tüübi ja mille heidame Stringile ja proovime siis turvaliselt? stringi teisendamiseks NSRegularExpressioniks.

See trafo on siis saadaval kõikjal use kasutamiseks

Vigade käsitlemine

Veakäsitluse testimiseks kasutan JSON-faili puuduva väljundvõtmega.

ObjectMapperi kaudu selle käivitamisel kuvatakse kena kasulik veateade.

Sai kaardistamisel viga.
- põhjus: 'Stringi' ei saa üle anda
- asukoht: Config.init (kaart :): 30
- võti: väljund
- currentValue: null

See ütleb meile kõik, mida vajame probleemi kiireks leidmiseks. AlamofireObjectMapperi integratsiooni kasutamisel leiti, et vead summutatakse, mis on vähem kui ideaalne.

Kodeeritav

Karbist välja vastav ekvivalentne teostus on järgmine

See on väga sarnane ObjectMapperiga, ehkki võtmeid määratletakse CodingKey protokolli abil enumidena.

Covablei kasutamisel on tõeliselt tore funktsioon, mille korral saate algataja teile genereerida, kui nende juhtumid on omandiga võrdsed ja tüüp, mida kaardistame, on ise dekoreeritav. Selle näide on ülaltoodud CodableConfig. Kuna kõik selle omadused on ise dekoreeritavad, ei pea me algatajat kirjutama!

Kinnitamine

See töötab täpselt samamoodi nagu ObjectMapper

Initsiaator viskab vea, kui ilmneb tõrkekaart, mida saab kõne saidil käsitleda. Jällegi kasutage siinkohal valikulisi, et otsustada, kuidas kõige paremini vigu käsitleda.

Kohandatud ümberkujundamine

Ülaltoodud koodis märkate, et see kõik muutub natuke vähem selgeks, kui proovime kaardistada meie NSRegularExpression tüüpi. Peame ootamatult rakendama algataja init (dekoodrilt: dekooder) ja hankima endale dekoodrilt KeyedDecodingContaineri

Selle kohta on juba palju kirjutatud, kui soovite rohkem üksikasju, mida ma ei kavatse siin üle vaadata.

Kood muutub nüüd kirjutamiseks üsna paljusõnaliseks ja me kordame teisenduskoodi. Sel juhul on see ainult lisarida, kuid sageli on vaja kirjutada keerulisemaid teisendusi, mida soovin eraldada nii, nagu saan ObjectMapperi abil

Tegin siis väikese raamatukogu kohandatud ümberkujundamise toetamiseks - see on saadaval CocoaPodsi kaudu või võite lihtsalt allika kopeerida, kuna see on vaid paar faili.

Võite kaaluda laienduse lisamist tüübile, mis te ei kuulu, kuid seal on hea selgitus, miks see pole Swift Evolutionis võimalik.

CodableExtensions teeki kasutades saame nüüd oma koodi lihtsustada, et see näeks välja väga sarnane ObjectMapperiga

Ja ka RegexCodableTransformer on väga sarnane sellele, mis meil varem ObjectMapperiga oli

Teek lihtsustab ka liidese container.decode () liidest, nii et seda tüüpi ei pea enam järeldama.

Vigade käsitlemine

Ma kasutan sama JSON-faili, et võrrelda veakäsitlust nagu varem. Viga näeb välja selline

keyNotFound (config_spike.CodableRewriter. (CodingKeys in _4D474241C6D85B5C48988D77CA644850). väljund, Swift.DecodingError.Context (codingPath: [config_spike.CodableC48D4 ").", aluseks olev viga: null))

Viga pole just nii ilus , kuid probleemi silumiseks on kõik olemas.

Järeldus

Kahe lähenemisviisi vahel on palju rohkem sarnasusi kui erinevusi. Kui teisendused on olulised, töötab ObjectMapper karbist välja. Üks peamisi motivatsioone üleminekul on siiski üleminek standardile, mille Apple on loonud, ilma et peaksite mõnda teist teeki sisse tooma.

Kui teisendused on olulised, saate paari protokolli lisamisega sama käitumise ka Codableiga

Oleme otsustanud, et kõik meie uued funktsioonid lähevad edasi Coidedisse. Olen kindel, et selles loendis on mul puudu funktsioone, kuid valisin meie jaoks kõige olulisemad.