Το μοντέλο-View-Controller είναι νεκρό στο μπροστινό μέρος;

Όλο και περισσότεροι προγραμματιστές front-end υιοθετούν μονοκατευθυντικές αρχιτεκτονικές. Ποιο είναι λοιπόν το μέλλον της κλασικής προσέγγισης Model-View-Controller (MVC);

Για να καταλάβουμε πώς φτάσαμε σε αυτό το σημείο, ας εξετάσουμε πρώτα την εξέλιξη της αρχιτεκτονικής front-end.

Τα τελευταία τέσσερα χρόνια, έχω εργαστεί σε πολλά διαδικτυακά έργα και έχω περάσει αρκετό χρόνο για τη δημιουργία πρωτοβουλιών και την ενσωμάτωση πλαισίου σε αυτά.

Πριν από το 2010, η JavaScript - στην οποία γράφτηκε η γλώσσα προγραμματισμού jQuery - χρησιμοποιήθηκε κυρίως για την προσθήκη χειρισμού DOM σε παραδοσιακούς ιστότοπους. Οι προγραμματιστές δεν φαίνεται να ενδιαφέρονται πολύ για την ίδια την αρχιτεκτονική. Πράγματα όπως το αποκαλυπτικό μοτίβο λειτουργικής μονάδας ήταν αρκετά καλό για να δομήσουν τις βάσεις κώδικα μας.

Η τρέχουσα συζήτησή μας για την αρχιτεκτονική front-end έναντι back-end ξεκίνησε μόνο στα τέλη του 2010. Τότε οι προγραμματιστές άρχισαν να λαμβάνουν σοβαρά υπόψη την έννοια μιας εφαρμογής μιας σελίδας . Αυτό συμβαίνει επίσης όταν άρχισαν να γίνονται δημοφιλή πλαίσια όπως το Backbone και το Knockout.

Δεδομένου ότι πολλές από τις αρχές που χτίστηκαν αυτά τα πλαίσια ήταν αρκετά νέες τότε, οι σχεδιαστές τους έπρεπε να κοιτάξουν αλλού για έμπνευση. Δανείστηκαν πρακτικές που είχαν ήδη καθιερωθεί για αρχιτεκτονική από διακομιστή. Και εκείνη τη στιγμή, όλα τα δημοφιλή πλαίσια διακομιστή περιελάμβαναν κάποιο είδος εφαρμογής του κλασικού μοντέλου MVC (επίσης γνωστό ως MV * λόγω των παραλλαγών του).

Όταν το React.js παρουσιάστηκε για πρώτη φορά ως μια βιβλιοθήκη απόδοσης, πολλοί προγραμματιστές το κοροϊδεύτηκαν επειδή θεωρούσαν τον τρόπο αντιμετώπισης του HTML σε JavaScript ως αντιδιαισθητικός. Αλλά παραβλέπουν την πιο σημαντική συνεισφορά που έφερε ο React στο τραπέζι - Αρχιτεκτονική με βάση τα συστατικά .

Το React δεν εφευρέθηκε συστατικά, αλλά πήρε αυτήν την ιδέα ένα βήμα παραπέρα.

Αυτή η σημαντική ανακάλυψη στην αρχιτεκτονική παραβλέφθηκε ακόμη και από το Facebook, όταν διαφήμισαν το React ως το "V in the MVC".

Σε μια δευτερεύουσα νότα, έχω ακόμα εφιάλτες μετά την αναθεώρηση μιας βάσης κώδικα που είχε τόσο το Angular 1.x όσο και το React να συνεργάζονται.

Το 2015 μας έφερε μια σημαντική αλλαγή στη νοοτροπία - από το γνωστό μοτίβο MVC στις Μονοκατευθυντικές Αρχιτεκτονικές και Ροές Δεδομένων που προέρχονται από το Flux και το Functional Reactive Programming, υποστηριζόμενα από εργαλεία όπως το Redux ή το RxJS.

Λοιπόν, πού πήγαν όλα λάθος για το MVC;

Το MVC εξακολουθεί να είναι ο καλύτερος τρόπος αντιμετώπισης του διακομιστή. Πλαίσια όπως το Rails και το Django είναι ευχάριστο να συνεργαστούμε.

Τα προβλήματα προέρχονται από το γεγονός ότι οι αρχές και οι διαχωρισμοί που εισήγαγε το MVC στον διακομιστή δεν είναι οι ίδιοι με τον πελάτη.

Σύζευξη ελεγκτή-προβολής

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

Όταν μετακινείτε στο MVC στον υπολογιστή-πελάτη, υπάρχει πρόβλημα. Οι ελεγκτές μοιάζουν με αυτό που αποκαλούμε «code-behind». Ο ελεγκτής εξαρτάται σε μεγάλο βαθμό από την προβολή. Στις περισσότερες εφαρμογές πλαισίου, δημιουργείται ακόμη και από το View (όπως συμβαίνει, για παράδειγμα, με το ng-controller στο Angular).

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

Μοντέλα λίπους

Σκεφτείτε λίγο για το είδος των δεδομένων που αποθηκεύετε σε ένα μοντέλο από την πλευρά του πελάτη.

Από τη μία πλευρά, έχετε δεδομένα όπως χρήστες και προϊόντα , τα οποία αντιπροσωπεύουν την κατάσταση εφαρμογής σας . Από την άλλη πλευρά, πρέπει να αποθηκεύσετε την κατάσταση διεπαφής χρήστη - πράγματα όπως showTab ή επιλεγμένη τιμή .

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

Λοιπόν, πού ταιριάζουν τα εξαρτήματα σε αυτό το μοντέλο;

Τα στοιχεία είναι: Προβολές + Διαχείριση συμβάντων + Κατάσταση διεπαφής χρήστη .

Το παρακάτω διάγραμμα δείχνει πώς πραγματικά διαιρέσατε το αρχικό μοντέλο MVC για να αποκτήσετε τα στοιχεία. Αυτό που μένει πάνω από τη γραμμή είναι ακριβώς αυτό που προσπαθεί να λύσει η Flux : διαχείριση της Κατάστασης Εφαρμογών και της Επιχειρηματικής Λογικής .

Με τη δημοτικότητα της αρχιτεκτονικής React και βασισμένων σε στοιχεία , είδαμε την άνοδο των μονοκατευθυντικών αρχιτεκτονικών για τη διαχείριση της κατάστασης εφαρμογής.

Ένας από τους λόγους που αυτοί οι δύο ταιριάζουν τόσο καλά είναι ότι καλύπτουν πλήρως την κλασική προσέγγιση MVC. Παρέχουν επίσης έναν πολύ καλύτερο διαχωρισμό των ανησυχιών όσον αφορά την κατασκευή αρχιτεκτονικών front-end.

Αλλά αυτό δεν είναι πλέον μια ιστορία React. Αν κοιτάξετε το Angular 2, θα δείτε το ίδιο ακριβώς μοτίβο να εφαρμόζεται, παρόλο που έχετε διαφορετικές επιλογές για τη διαχείριση της κατάστασης εφαρμογής όπως το ngrx / store.

Δεν υπήρχε πραγματικά τίποτα που θα μπορούσε να κάνει καλύτερα το MVC στον πελάτη. Ήταν καταδικασμένο να αποτύχει από την αρχή. Χρειαζόμασταν μόνο χρόνο για να το δούμε. Μέσω αυτής της πενταετούς διαδικασίας, η αρχιτεκτονική front-end εξελίχθηκε σε αυτήν που είναι σήμερα. Και όταν το σκέφτεστε, πέντε χρόνια δεν είναι τόσο μεγάλο χρονικό διάστημα για την εμφάνιση βέλτιστων πρακτικών.

Το MVC ήταν απαραίτητο στην αρχή, επειδή οι εφαρμογές front-end μας γίνονταν μεγαλύτερες και πιο περίπλοκες και δεν ξέραμε πώς να τις δομήσουμε. Νομίζω ότι εξυπηρετούσε τον σκοπό του, παρέχοντας παράλληλα ένα καλό μάθημα για τη λήψη μιας καλής πρακτικής από ένα περιβάλλον (τον διακομιστή) και την εφαρμογή του σε άλλο (ο πελάτης)

Τι ισχύει λοιπόν το μέλλον;

Δεν νομίζω ότι θα επιστρέψουμε στην κλασική αρχιτεκτονική MVC σύντομα για τις εφαρμογές διεπαφής.

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

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

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

Για αυτό πρόκειται! Ελπίζω να σας άρεσε να το διαβάζετε. Χαιρετίζω τα σχόλιά σας παρακάτω.

Αν σας άρεσε το άρθρο, κάντε κλικ στην πράσινη καρδιά παρακάτω και θα ξέρω ότι οι προσπάθειές μου δεν είναι μάταιες.