Γιατί το ORM δεν πρέπει να είναι το καλύτερο στοίχημά σας

Όταν άρχισα να προγραμματίζω, λίγα χρόνια πίσω, το ORM ήταν σαν το ζωτικό αίμα των προγραμμάτων λογισμικού. Το περιβάλλον υπογράμμισε τη στενή σύζευξη μεταξύ της βάσης κώδικα και της στρώσης ORM. Μπορεί να ειπωθεί ότι είχα εκπαιδευτεί να μην σκέφτομαι έργα χωρίς ORM.

Όμως, καθώς απέκτησα εμπειρία και βαθύτερη γνώση συγκεκριμένων έργων, συνειδητοποίησα ότι οι περισσότερες βελτιώσεις τελικά έρχονται στο σημείο όπου η ροή εισέρχεται στο πλαίσιο ORM. Αυτό ήταν όταν ρώτησα τον εαυτό μου: τι εάν το έργο αυτό δεν είχε ORM;

Άρχισα να σκέφτομαι τα προβλήματα που είχε θέσει ο ORM:

  • Δεν μπορείτε να βελτιστοποιήσετε τον κώδικα σας, ακόμη και αν χρειάζεστε πραγματικά αυτή την επιπλέον έκρηξη ταχύτητας. Ο κώδικας ORM ζει σε μια δική του γη.
  • Η ορατότητα στο τι συμβαίνει είναι το ελάχιστο.
  • Η τεκμηρίωση είναι συνήθως μαζική και κατακερματισμένη καθιστώντας δύσκολη την αναζήτηση ειδικών χαρακτηριστικών.

Αυτά μπορεί να ακούγονται σαν μικρά προβλήματα, αλλά βλάπτουν σημαντικά την παραγωγικότητα. Εκτός από αυτά, συνειδητοποίησα ότι το οικοσύστημα ORM αποσπάται από την mainstream ανάπτυξη ιστοσελίδων με το δικό του εμπορικό σήμα ζητημάτων και περιορισμών. Τα ORMs γενικά φέρνουν περιττή πολυπλοκότητα, παρέχοντας "διαρροές διαρροής" πάνω από τις αλληλεπιδράσεις της βάσης δεδομένων. Μερικές φορές έχουν μια απότομη καμπύλη μάθησης και οι προγραμματιστές τείνουν να τα αντιμετωπίζουν ως blackboxes.

Έχω δει προγραμματιστές να ακολουθήσουν διάφορες προσεγγίσεις για την αντιμετώπιση του προβλήματος ORM. Κάποιοι απομακρύνονται εντελώς από τα πλαίσια ORM, τα οποία είναι συχνά Herculean έργο ανάλογα με την πολυπλοκότητα του έργου. Μερικοί αποδέχονται το ORM και προσαρμόζουν κώδικα στο έργο τους. είναι έτοιμοι να συμβιβαστούν στην απόδοση και δεν ενδιαφέρονται για την πρόσθετη πολυπλοκότητα. Πολλοί από αυτούς επιλέγουν το χρυσό μονοπάτι όπου συνεχίζουν να χρησιμοποιούν το ORM, αλλά αποκλείονται νέα ή περίπλοκα ερωτήματα. Ορισμένοι από αυτούς δημιουργούν το δικό τους στρώμα χαρτογράφησης ειδικά για το έργο και ανάλογα με την ανάγκη.

Μέχρι στιγμής, έχω συνεργαστεί με το Hibernate (Java) και το Mongoose (πλαίσιο ORM στο κόμβο για το MongoDB). Όταν ήρθα σε ένα έργο κόμβου που χρησιμοποιούσε ήδη το Mongoose ως ORM, είχα το μνημειώδες καθήκον να αναδιαμορφώσω σχεδόν όλο το έργο. Αρχικά σκέφτηκα να αφαιρέσω το πλαίσιο ORM συνολικά. Αλλά οι συνάδελφοί μου δεν θα ήταν ικανοποιημένοι χωρίς αριθμούς που με στήριξαν. Επομένως, έκανα συγκριτική αξιολόγηση του χρόνου ερωτήματος με και χωρίς Mongoose. Εδώ είναι τα αποτελέσματα.

Μου πήρε από έκπληξη. Είχα αναμείνει κέρδος απόδοσης όταν δεν χρησιμοποιούσε Mongoose αλλά όχι σε τέτοιο βαθμό. Με αυτά τα δεδομένα στο χέρι η επιλογή ήταν σαφής: η ORM ήταν έξω. Λίγους μήνες αργότερα, ένας συνάδελφος με ρώτησε αν πρέπει να χρησιμοποιήσουν το Sequelize ή το Pg για να αποκτήσουν πρόσβαση σε μια βάση δεδομένων Postgres. Συνειδητοποιώντας ότι το Sequelize ήταν ένα ORM, έδωσα την ψήφο μου στην Pg, αλλά τον ζήτησα να συγκρίνει τα δύο. Ήθελα να ελέγξω αν το μίσος του ORM ήταν δικαιολογημένο και όταν οι αριθμοί επέστρεφαν, αποδεικνύεται ότι ήταν πράγματι απολύτως δικαιολογημένο.

Μαντέψτε ποια βιβλιοθήκη προχώρησε.

Ένα πράγμα που πρέπει να θυμόμαστε εδώ είναι όταν εγκαταλείψαμε τα ORMs, είτε πρόκειται για Mongoose είτε για Sequelize, γνωρίζαμε τι ήταν αυτό που εγκατέλειπε. Συγκεκριμένα, ο έλεγχος των σχημάτων, οι προ-δομημένες μέθοδοι, οι αφαίρεσεις κλπ. Ήταν τα πλεονεκτήματα της χρήσης ενός πλαισίου ORM. Μια μεγάλη ανησυχία ήταν η έλλειψη ελέγχου των σχημάτων (όταν δεν χρησιμοποιήθηκαν ORMs), κάτι που θα μπορούσε να οδηγήσει σε άσχημα δεδομένα που εισέρχονται στο ΣΠ. Για να το πετύχουμε, χρησιμοποιήσαμε το Joi, το οποίο καθιστούσε ευκολότερη την εργασία μας διατηρώντας ανέπαφη την απόδοση. Για άλλα μέρη χρειαζόμασταν να γράψουμε μερικές σειρές πρόσθετου κώδικα, αλλά αξίζει τον κόπο. Καλύτερα από χάνουν δεκάδες χιλιοστά του δευτερολέπτου (μερικές φορές ακόμη και δευτερόλεπτα) σε κάθε ερώτημα.

Δεν προσπαθώ να βάσω τα ORM και είναι πραγματικά καλό για τους αρχάριους και τα έργα μικρής κλίμακας. Αλλά όταν το σχέδιό σας κλιμακώνεται σε μεγάλο αριθμό ερωτημάτων και εγγράφων, τα ORM μπορούν να καταστούν εμπόδιο. Σκεφτείτε τους ως πόλεμο του Βιετνάμ, θα πρέπει να αποφασίσετε πότε να βγείτε και να τρέξετε, ή αλλιώς σημαντικές ζημιές είναι αναπόφευκτες.