Hvorfor ORM ikke burde være det beste alternativet

Da jeg begynte å programmere, for noen år tilbake, var ORM som livsblodet til programvareprosjekter. Miljøet la vekt på den tette koblingen mellom kodebasen og ORM-laget. Det kan sies at jeg ble opplært til ikke å tenke på prosjekter uten en ORM.

Men etter hvert som jeg fikk erfaring og dypere kunnskap om spesifikke prosjekter, innså jeg at de fleste forbedringene til slutt kommer til det punktet hvor strømmen gikk inn i ORM-rammeverket. Det var da jeg spurte meg selv: hva om dette prosjektet ikke hadde noen ORM?

Jeg begynte å tenke på problemene ORM hadde introdusert:

  • Du kan ikke optimalisere koden selv om du virkelig trenger den ekstra hastigheten; ORM-koden bor i et eget land.
  • Synligheten til hva som skjer er på et minimum.
  • Dokumentasjonen er vanligvis massiv og fragmentert, noe som gjør det vanskelig å søke etter detaljer.

Disse kan høres ut som små problemer, men de skader produktiviteten betydelig. Bortsett fra disse, innså jeg at ORM-økosystemet er løsrevet fra mainstream webutvikling med sitt eget merke av problemer og begrensninger. ORM-er bringer unødvendig kompleksitet, og gir "lekker abstraksjon" over databaseinteraksjoner. Noen ganger har de en bratt læringskurve, og utviklere har en tendens til å behandle dem som en blackboxes.

Jeg har sett utviklere ta forskjellige tilnærminger for å takle ORM-problemet. Noen fjerner ORM-rammer fullstendig, noe som ofte er en Herculean oppgave, avhengig av kompleksiteten i prosjektet. Noen godtar ORM og tilpasser kode i prosjektet sitt; de er klare til å gå på akkord med ytelsen og bryr seg ikke om den ekstra kompleksiteten. Mange av dem velger den gyldne banen der de fortsetter å bruke ORM, men nye eller komplekse spørsmål er utelukket. Noen av dem lager faktisk sitt eget kartleggingslag som er spesifikt for prosjektet og etter behov.

Så langt har jeg jobbet med Hibernate (Java), og Mongoose (ORM framework i Node for MongoDB). Da jeg kom til et Node-prosjekt som allerede brukte Mongoose som en ORM, hadde jeg den monumentale oppgaven å refaktere nesten hele prosjektet. Først tenkte jeg på å fjerne ORM-rammeverket helt. Men mine kolleger ville ikke være fornøyd uten at tallene støttet meg. Så jeg benchmarket spørringstiden med og uten Mongoose. Her er resultatene.

De overrasket meg. Jeg hadde forventet en ytelsesgevinst når jeg ikke brukte Mongoose, men ikke i denne grad. Med disse dataene i hånden var valget klart: ORM var ute. Noen måneder senere spurte en kollega meg om de skulle bruke Sequelize eller Pg for å få tilgang til en Postgres-database. Når jeg skjønte at Sequelize var en ORM, ga jeg stemmen til Pg, men ba ham om å sammenligne de to. Jeg ønsket å bekrefte om ORM-hatet var berettiget, og når tallene kom tilbake, viser det seg at det faktisk var helt berettiget.

Gjett hvilket bibliotek han gikk foran med.

En ting å huske her er da vi ga opp ORMer, det være seg Mongoose eller Sequelize, vi var klar over hva det var som ga opp. Spesielt skjemasjekking, forhåndsbygde metoder, abstraksjoner etc. var fordelene ved å bruke et ORM-rammeverk. En stor bekymring var mangelen på skjemakontroll (når du ikke bruker ORMer), noe som kan føre til dårlige data inn i DB. For å komme oss rundt dette brukte vi Joi, noe som gjorde oppgaven vår enklere og holdt ytelsen intakt. For andre deler trengte vi å skrive noen få linjer med ekstra kode, men det var verdt det. Bedre det enn å tape flere titalls millisekunder (noen ganger til og med sekunder) på hvert spørsmål.

Jeg prøver ikke å basere ORM-er, og de er veldig bra for nybegynnere og småskalaprosjekter. Men når prosjektet skaleres til et stort antall spørsmål og dokumenter, kan ORM-er bli en flaskehals. Tenk på dem som Vietnam-krigen, du må bestemme når du skal trekke ut og løpe, ellers er store skader uunngåelige.