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

Το μάθημα εισάγει τις δυνατότητες δημιουργίας μιας διαδικτυακής εφαρμογής χρησιμοποιώντας ASP.NET MVCαπό το .NET Framework 4.5., με δυνατότητα βελτίωσης της απόδοσης και της επεκτασιμότητας των αναπτυγμένων εφαρμογών Web. Δίνεται μεγάλη προσοχή στη σύγκριση των τεχνολογιών ASP.NET MVC και ASP.NET Web Forms και των κριτηρίων για την επιλογή μιας ή άλλης τεχνολογίας.

Η επιτυχής ολοκλήρωση αυτού του μαθήματος θα επιτρέψει στους ειδικούς να:

• Περιγράψτε τις κύριες τεχνολογίες της Microsoft στον τομέα της ανάπτυξης ιστοσελίδων και επιλέξτε τις καταλληλότερες για να λύσετε τα προβλήματά σας.
• Σχεδιάστε διαδικτυακές εφαρμογές που πληρούν διάφορες απαιτήσεις.
• Δημιουργήστε μοντέλα προτύπων MVC και εφαρμόστε επιχειρηματική λογική σε αυτά τα μοντέλα.
• Δημιουργήστε ελεγκτές εφαρμογών MVC που αλληλεπιδρούν με χρήστες, μοντέλα και προβολές.
• Δημιουργήστε προβολές εφαρμογών MVC για εμφάνιση και επεξεργασία δεδομένων, καθώς και για αλληλεπίδραση με μοντέλα και ελεγκτές.
• Δημιουργήστε δοκιμές μονάδας και χρησιμοποιήστε εργαλεία εντοπισμού σφαλμάτων του Visual Studio 2012 κατά την ανάπτυξη εφαρμογών Ιστού.
• Δημιουργήστε εφαρμογές ιστού που χρησιμοποιούν διευθύνσεις URL αναγνώσιμες από τον άνθρωπο.
• Χρησιμοποιήστε μια ενιαία διεπαφή και στυλ στην εφαρμογή MVC.
• Επιταχύνετε την αλληλεπίδραση των χρηστών με προσωρινή αποθήκευση και μερική ανανέωση σελίδων.
• Δημιουργήστε κώδικα πελάτη σε JavaScript χρησιμοποιώντας τη βιβλιοθήκη jQuery.
• Δημιουργήστε ασφαλείς εφαρμογές MVC.
• Χρησιμοποιήστε τις υπηρεσίες web των Windows Azure από την εφαρμογή MVC.
• Αναπτύξτε εφαρμογές MVC.

Σκοπός του μαθήματος

Διαμόρφωση γνώσεων και δεξιοτήτων για τη δημιουργία εφαρμογών Web με χρήση ASP.NET MVC από το .NET Framework 4.5.

Το κοινό-στόχος

Έμπειροι προγραμματιστές ιστούμε εμπειρία στη δημιουργία εφαρμογών με χρήση του Visual Studio.

Απαραίτητη προετοιμασία

• Μάθημα 10267 "Εισαγωγή στην ανάπτυξη εφαρμογών Web με χρήση του Microsoft Visual Studio 2010" ή ισοδύναμη εκπαίδευση.
• Μάθημα HTML και CSS. Επίπεδο 1. Δημιουργία ιστοσελίδων σύμφωνα με τα πρότυπα του W3C και μετάβαση σε HTML 5 και CSS 3.

1. Επισκόπηση ASP.NET MVC 4

• Ανασκόπηση των τεχνολογιών web της Microsoft.
• Επισκόπηση ASP.NET 4.5.
• Εισαγωγή στο ASP.NET MVC 4.

2. Σχεδιασμός μιας διαδικτυακής εφαρμογής ASP.NET MVC 4.

• Μοντέλα αρχιτεκτονικού σχεδιασμού.
• Αρχιτεκτονικός σχεδιασμός Ελεγκτών.
• Αρχιτεκτονικός Σχεδιασμός Απόψεων.
• Αρχιτεκτονικός σχεδιασμός της εφαρμογής.

3. Ανάπτυξη μοντέλων ASP.NET MVC 4.

• Δημιουργία MVC Models (Models).
• Εργασία με δεδομένα.

4. Ανάπτυξη ελεγκτών ASP.NET MVC 4.

• Δημιουργία Ελεγκτών και τις Ενέργειές τους.
• Δημιουργία φίλτρων ενεργειών για μεθόδους.

5. Ανάπτυξη ASP.NET MVC 4 Views.

• Δημιουργία προβολών χρησιμοποιώντας τη μηχανή Razor.
• Χρήση βοηθών HTML.
• Επαναχρησιμοποίηση κώδικα στις Προβολές.

6. Δοκιμή και εντοπισμός σφαλμάτων εφαρμογών web ASP.NET MVC 4.

• Δημιουργία δοκιμών μονάδας.
• Διαμόρφωση χειρισμού εξαιρέσεων.

7. Δόμηση εφαρμογών web ASP.NET MVC 4.

• Διαμόρφωση προτύπων URL.
• Δημιουργία στοιχείων ελέγχου πλοήγησης.

8. Εφαρμογή στυλ στην εφαρμογή web ASP.NET MVC 4.

• Χρήση προτύπων προβολής.
• Εφαρμογή στυλ CSS σε μια εφαρμογή MVC.
• Δημιουργία μιας ανταποκρινόμενης διεπαφής χρήστη.

9. Δημιουργία διαδραστικών σελίδων στην εφαρμογή web ASP.NET MVC 4.

• Χρήση AJAX και μερική ανανέωση σελίδας.
• Στρατηγική προσωρινής αποθήκευσης.

10. Χρήση JavaScript και jQuery για τη δημιουργία διαδραστικών σελίδων.

• Τοποθέτηση και εκτέλεση JavaScript στη σελίδα.
• Χρήση jQuery και jQueryUI.

11. Περιορισμός πρόσβασης στην εφαρμογή web ASP.NET MVC 4.

• Έλεγχος ταυτότητας και εξουσιοδότηση.
• Ανάθεση ρόλων.

12. Ασφάλεια στην εφαρμογή web ASP.NET MVC 4.

• Δημιουργία αξιόπιστων τοποθεσιών.
• Κατάσταση αποταμίευσης.

13. Χρήση υπηρεσιών web των Windows Azure σε μια εφαρμογή web ASP.NET MVC 4.

• Εισαγωγή στο Windows Azure.
• Σχεδιασμός και υλοποίηση υπηρεσιών web Windows Azure.
• Χρήση υπηρεσιών web των Windows Azure σε μια εφαρμογή Ιστού.

14. Υλοποίηση WebAPI σε web εφαρμογή ASP.NET MVC 4.

• Ανάπτυξη WebAPI.
• Χρήση WebAPI σε εφαρμογές για κινητά και web.

15. Επεξεργασία αιτημάτων σε εφαρμογή web ASP.NET MVC 4.

• Χρήση μονάδων HTTP και χειριστών.
• Χρήση Web Sockets.

16. Ανάπτυξη της εφαρμογής web ASP.NET MVC 4.

• Ανάπτυξη μιας διαδικτυακής εφαρμογής.
• Ανάπτυξη μιας εφαρμογής MVC 4.

Έγγραφο που ελήφθη

Πιστοποιητικόσχετικά με την προχωρημένη εκπαίδευση ή Πιστοποιητικό.(Ανάλογα με την κατηγορία των ακροατών και τη συνολική διάρκεια του προγράμματος)

Η έννοια του MVC (Model-View-Controller) αναφέρεται πολύ συχνά στον κόσμο του web προγραμματισμού τα τελευταία χρόνια. Όλοι όσοι συνδέονται με οποιονδήποτε τρόπο με την ανάπτυξη εφαρμογών Ιστού έχουν συναντήσει αυτό το αρκτικόλεξο με τον ένα ή τον άλλο τρόπο. Σήμερα θα καταλάβουμε τι είναι η έννοια MVC και γιατί έγινε δημοφιλής.

Αρχαία ιστορία

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

Περιγράφηκε για πρώτη φορά το 1979, φυσικά, για ένα διαφορετικό περιβάλλον. Τότε δεν υπήρχε η ιδέα μιας διαδικτυακής εφαρμογής. Ο Tim Berners Lee έσπειρε τους σπόρους του World Wide Web (WWW) στις αρχές της δεκαετίας του '90 και άλλαξε τον κόσμο για πάντα. Το πρότυπο που χρησιμοποιούμε σήμερα είναι μια προσαρμογή του αρχικού προτύπου για την ανάπτυξη ιστού.

Η άγρια ​​δημοτικότητα αυτής της δομής σε εφαρμογές web οφειλόταν στη συμπερίληψή της σε δύο περιβάλλοντα ανάπτυξης που έγιναν πολύ δημοφιλή: το Struts και το Ruby on Rails. Αυτά τα δύο περιβάλλοντα ανάπτυξης έθεσαν το δρόμο για εκατοντάδες περιβάλλοντα ανάπτυξης που δημιουργήθηκαν αργότερα.

MVC για εφαρμογές web

Η ιδέα πίσω από το μοτίβο σχεδιασμού MVC είναι πολύ απλή: πρέπει να διαχωρίσουμε σαφώς τις ευθύνες για τις διάφορες λειτουργίες στις εφαρμογές μας:

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

Ελεγκτής

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

Μοντέλο

Μοντέλο- Αυτά είναι τα δεδομένα και οι κανόνες που χρησιμοποιούνται για την εργασία με τα δεδομένα που αντιπροσωπεύουν την έννοια της διαχείρισης της εφαρμογής. Σε οποιαδήποτε εφαρμογή, ολόκληρη η δομή μοντελοποιείται ως δεδομένα που επεξεργάζονται με συγκεκριμένο τρόπο. Τι είναι ένας χρήστης για μια εφαρμογή - ένα μήνυμα ή ένα βιβλίο; Μόνο δεδομένα που πρέπει να υποβάλλονται σε επεξεργασία σύμφωνα με κανόνες (η ημερομηνία δεν μπορεί να δείχνει στο μέλλον, το email πρέπει να είναι σε συγκεκριμένη μορφή, το όνομα δεν μπορεί να είναι μεγαλύτερο από X χαρακτήρες κ.λπ.).

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

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

Θέα

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

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

Ας δούμε ένα παράδειγμα

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

Έχουμε ένα συγκεκριμένο ελεγκτή για να χειριζόμαστε όλες τις ενέργειες που σχετίζονται με βιβλία (προβολή, επεξεργασία, δημιουργία κ.λπ.). Ας το ονομάσουμε books_controller.phpστο παράδειγμά μας. Χρειαζόμαστε επίσης ένα μοντέλο όπως book_model.php, το οποίο επεξεργάζεται τα δεδομένα και τη λογική που σχετίζονται με ένα αντικείμενο καταστήματος. Συμπερασματικά, χρειαζόμαστε πολλές προβολές για την αναπαράσταση των δεδομένων, όπως μια λίστα βιβλίων, μια σελίδα επεξεργασίας και ούτω καθεξής.

Το παρακάτω σχήμα δείχνει πώς γίνεται η επεξεργασία του αιτήματος ενός χρήστη για προβολή μιας λίστας βιβλίων για ένα θέμα φαντασία:

Ο ελεγκτής (books_controller.php) λαμβάνει το αίτημα χρήστη (αίτημα HTTP GET ή POST). Μπορούμε να δημιουργήσουμε έναν κεντρικό ελεγκτή, για παράδειγμα index.php, ο οποίος λαμβάνει το αίτημα και καλεί το books_controller.php.

Ο ελεγκτής ελέγχει το αίτημα και τις παραμέτρους και στη συνέχεια καλεί το μοντέλο(book_model.php), ζητώνταςέχει μια λίστα με διαθέσιμα βιβλία για το θέμα φαντασία .

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

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

Ποια είναι τα πλεονεκτήματα;

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

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

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

Γιατί να χρησιμοποιήσετε το εργασιακό περιβάλλον;

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

Ας δούμε το cakePHP ως παράδειγμα πάγκου εργασίας MVC. Μετά την εγκατάσταση θα έχετε τρεις κύριους καταλόγους:

• κέικ/
• πωλητές/

Ντοσιέ εφαρμογήείναι όπου βρίσκονται τα αρχεία σας. Αυτό είναι το μέρος για να αναπτύξετε το μέρος της εφαρμογής σας.

Σε φάκελο κέικΤα αρχεία cakePHP (λειτουργικότητα πάγκου εργασίας) φιλοξενούνται.

Ντοσιέ πωλητέςχρησιμεύει για την αποθήκευση βιβλιοθηκών PHP τρίτων.

Ο χώρος εργασίας σας (κατάλογος εφαρμογών) έχει την ακόλουθη δομή:

• app/
  • config/
  • ελεγκτές/
  • μικρός λοβός/
  • μοντέλα/
  • πρόσθετα/
  • τεστ/
  • πωλητές/
  • προβολές/
  • webroot/

Πρέπει να τοποθετήσετε τους ελεγκτές σας σε έναν κατάλογο ελεγκτές, μοντέλα στον κατάλογο μοντέλακαι τύπους στον κατάλογο προβολές!

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

Χρησιμοποιώντας τον πάγκο εργασίας για το παράδειγμά μας

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

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

Έτσι, μόλις ο χρήστης κάνει κλικ στο κουμπί, το πρόγραμμα περιήγησης ζητά τη δεδομένη διεύθυνση url:

www.ourstore.com/books/list/fantasy

Το CakePHP μορφοποιεί τη διεύθυνση URL χρησιμοποιώντας ένα μοτίβο /controller/action/param1/param2, Οπου δράσηείναι μια συνάρτηση που καλείται από τον ελεγκτή. Στην παλιά κλασική μορφή, το url θα μοιάζει με αυτό:

www.ourstore.com/books_controller.php?action=list&category=fantasy

Ελεγκτής

Στο περιβάλλον εργασίας cakePHP, ο ελεγκτής μας θα μοιάζει με αυτό:

class BooksController επεκτείνει το AppController (

Λίστα συναρτήσεων ($κατηγορία) (

$this->set("books", $this->Book->findAllByCategory($category));

Συνάρτηση add() ( ... ... )

Συνάρτηση delete() ( ... ... )

... ... } ?>

Απλό, έτσι δεν είναι; Αυτός ο ελεγκτής θα αποθηκευτεί ως books_controller.phpκαι δημοσιεύτηκε στο /app/controllers. Περιέχει μια λίστα συναρτήσεων που εκτελούν τις ενέργειες για το παράδειγμά μας, καθώς και άλλες λειτουργίες για την εκτέλεση λειτουργιών που σχετίζονται με βιβλία (προσθήκη νέου βιβλίου, διαγραφή βιβλίου κ.λπ.).

Το εργασιακό περιβάλλον μας παρέχει πολλές έτοιμες λύσεις και αρκεί να δημιουργήσουμε μια λίστα με βιβλία. Υπάρχει μια βασική κλάση που ήδη ορίζει τη βασική λειτουργικότητα του ελεγκτή, επομένως πρέπει να κληρονομήσετε τις ιδιότητες και τις λειτουργίες αυτής της κλάσης ( AppControllerείναι ο κληρονόμος Ελεγκτής).

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

αυτό->Βιβλίο- αυτό είναι το μοντέλο μας και μέρος του κώδικα:

$this->Book->findAllByCategory($category)

λέει στο μοντέλο να επιστρέψει μια λίστα βιβλίων για το επιλεγμένο θέμα (θα εξετάσουμε το μοντέλο αργότερα).

Μέθοδος σειράστη γραμμή:

$this->set("books", $this->Book->findAllByCategory($category));

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

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

Μοντέλο

Το μοντέλο είναι ακόμα πιο απλό:

class Book επεκτείνει το AppModel (

Γιατί είναι άδειο; Επειδή κληρονομείται από μια βασική κλάση που παρέχει την απαιτούμενη λειτουργικότητα και πρέπει να χρησιμοποιήσουμε τη σύμβαση ονομασίας του CakePHP για να έχουμε το χρόνο εκτέλεσης να χειρίζεται αυτόματα όλες τις άλλες εργασίες. Για παράδειγμα, το cakePHP γνωρίζει με βάση το όνομά του ότι χρησιμοποιείται αυτό το μοντέλο BooksController, και ότι έχει πρόσβαση σε έναν πίνακα βάσης δεδομένων που ονομάζεται βιβλία.

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

Αποθηκεύστε τον κωδικό ως βιβλίο.phpσε φάκελο /app/models.

Θέα

Το μόνο που χρειάζεται να κάνουμε τώρα είναι να δημιουργήσουμε μια προβολή (τουλάχιστον μία) για τη λίστα ενεργειών. Η προβολή θα έχει κώδικα HTML και λίγες (όσο το δυνατόν λιγότερες) γραμμές κώδικα PHP για να περιηγηθούν στη σειρά των βιβλίων που παρέχει το μοντέλο.

Ονομα	Συγγραφέας	Τιμή

Όπως μπορείτε να δείτε, η προβολή δεν δημιουργεί μια πλήρη σελίδα, αλλά μόνο ένα τμήμα HTML (ένας πίνακας σε αυτήν την περίπτωση). Επειδή το CakePHP παρέχει έναν άλλο τρόπο για να ορίσετε ένα πρότυπο σελίδας και η προβολή εισάγεται σε αυτό το πρότυπο. Ο πάγκος εργασίας μας παρέχει επίσης ορισμένα βοηθητικά αντικείμενα για την εκτέλεση κοινών εργασιών κατά τη δημιουργία τμημάτων μιας σελίδας HTML (εισαγωγή φορμών, συνδέσμων, Ajax ή JavaScript).

Αποθηκεύστε την προβολή ως λίστα.ctp(η λίστα είναι το όνομα της ενέργειας και το ctp σημαίνει το πρότυπο CakePHP) στον φάκελο /app/views/books(γιατί είναι προβολή για ενέργεια ελεγκτή).

Έτσι εκτελούνται και τα τρία στοιχεία χρησιμοποιώντας τον πάγκο εργασίας CakePHP!

- Δεν καταλαβαίνω γιατί οι άνθρωποι θαυμάζουν τόσο πολύ αυτόν τον Καρούζο; Γλωσσοδεμένο, βουητό, τραγούδι - δεν μπορείς να καταλάβεις τίποτα!
-Έχεις ακούσει τον Καρούζο να τραγουδάει;
- Ναι, ο Ραμπίνοβιτς μου τραγούδησε από το τηλέφωνο κάτι από το ρεπερτόριό του.

ντετέκτιβ πληροφορικής. Μέρος πρώτο

Αντιλαμβάνομαι ότι το να γράψω ένα άλλο άρθρο για το θέμα Model-View-Controller είναι ανόητο και επιβλαβές για το «κάρμα». Ωστόσο, έχω πολύ προσωπική σχέση με αυτό το «μοτίβο» - ένα αποτυχημένο έργο, έξι μήνες ζωής και σκληρή δουλειά «στο καλάθι».

Ξαναγράψαμε το έργο, χωρίς MVC, απλά καθοδηγούμενοι από τις αρχές - ο κώδικας έπαψε να μοιάζει με μπάλα μακαρόνια και μειώθηκε στο μισό (περισσότερα για αυτό αργότερα, στο υποσχεμένο άρθρο σχετικά με τον τρόπο εφαρμογής των «αρχών» στο έργο μας) . Ήθελα όμως να καταλάβω τι κάναμε λάθος, ποιο ήταν το λάθος; Και για πολύ καιρό μελετήθηκε ό,τι περιείχε τη συντομογραφία MVC. Μέχρι που γνωρίσαμε τα πρωτότυπα έργα του δημιουργού – Trygve Reenskaug...

Και τότε όλα μπήκαν στη θέση τους. Αποδείχθηκε ότι στην πραγματικότητα επαναπροσδιορίζαμε το «αρχικό MVC» με βάση τις αρχές. Και αυτό που συχνά παρουσιάζεται ως MVC δεν έχει να κάνει με αυτό... αλλά και με καλή αρχιτεκτονική. Και αν κρίνουμε από το πόσοι άνθρωποι γράφουν για την ασυνέπεια του "κλασικού MVC", διαφωνούν γι' αυτό και επινοούν κάθε είδους τροποποιήσεις, δεν είμαστε οι μόνοι που αντιμετωπίζουμε αυτό το πρόβλημα.

Για περισσότερα από 30 χρόνια, οι ιδέες και οι λύσεις που συλλέγονται στο MVC παραμένουν οι πιο σημαντικές για την ανάπτυξη διεπαφών χρήστη. Αλλά παραδόξως, παρά την υπάρχουσα σύγχυση και την αφθονία των αντικρουόμενων ερμηνειών, οι προγραμματιστές συνεχίζουν να είναι ικανοποιημένοι με μεταχειρισμένες πληροφορίες, αντλώντας γνώσεις για το MVC από τη Wikipedia, μικρά άρθρα στο Διαδίκτυο και πλαίσια για την ανάπτυξη εφαρμογών Ιστού. Ο πιο «προχωρημένος» διάβασε τον Μάρτιν Φάουλερ. Και για κάποιο λόγο σχεδόν κανείς δεν στρέφεται σε πρωτογενείς πηγές. Αυτό είναι το κενό που θα ήθελα να καλύψω. Και ταυτόχρονα καταρρίπτουν κάποιους μύθους.

Μύθοι: Το MVC δημιουργήθηκε για τη γλώσσα SmallTalk

Η ιδέα του MVC διατυπώθηκε από τον Trygve Reenskaug ως αποτέλεσμα της δουλειάς του στη Xerox PARC το 1978/79. Κατά κανόνα, η δημιουργία του MVC συνδέεται με τη γλώσσα SmallTalk, αλλά αυτό δεν είναι απολύτως αληθές. Στην πραγματικότητα, ο Reenskaug εργάστηκε σε μια ομάδα που ανέπτυξε έναν φορητό υπολογιστή «για παιδιά όλων των ηλικιών», το Dynabook, με επικεφαλής τον Alan Kay.

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

Τότε/εκεί τέθηκαν τα θεμέλια της γραφικής διεπαφής και διαμορφώθηκε η έννοια της «φιλικής διεπαφής». Η γλώσσα SmallTalk αναπτύχθηκε επίσης, μαζί με αντικειμενοστρεφείς έννοιες προγραμματισμού, έτσι ώστε ένας μη εκπαιδευμένος χρήστης «να μπορεί να κατανοεί και να γράφει προγράμματα». Έτσι περιγράφει ο Steve Jobs αυτό που είδε στο Xerox PARC το 1979: Πώς ο Steve Jobs πήρε τις ιδέες του GUI από τη XEROX(από 6.30)

Το έργο πραγματοποιήθηκε για περίπου 10 χρόνια από μια ομάδα πολύ ισχυρών προγραμματιστών. Οι λύσεις, οι προσεγγίσεις, οι αρχές που βρέθηκαν ως αποτέλεσμα τόσο στον τομέα των διεπαφών χρήστη όσο και στον τομέα του αντικειμενοστρεφούς προγραμματισμού και γενικά στην ανάπτυξη μεγάλων και πολύπλοκων συστημάτων υπολογιστών συνοψίστηκαν σε κάποιο βαθμό από τον Reenskaug και αποτέλεσαν τη βάση της MVC. Έτσι, το MVC είναι πραγματικά, πρώτα και κύρια, μια συλλογή από καθοδηγητικές αρχιτεκτονικές ιδέες. Στο SmallTalk-80 αυτές οι ιδέες μόλις έλαβαν την πρώτη σημαντική εφαρμογή τους. Επιπλέον, αυτό έγινε μετά την αποχώρηση του Reenskaug από την Xerox PARC και χωρίς τη συμμετοχή του.

Δυστυχώς, για μεγάλο χρονικό διάστημα δεν υπήρχαν πρακτικά διαθέσιμες πληροφορίες σχετικά με το "πραγματικό MVC". Η πρώτη σοβαρή δημοσίευση από τους δημιουργούς εμφανίστηκε μόλις 10 χρόνια αργότερα - "Ένα βιβλίο μαγειρικής για τη χρήση του παραδείγματος διεπαφής χρήστη Model-View-Controller στο Smalltalk-80". Ακόμη και ο Fowler αναφέρει ότι έμαθε το MVC από μια λειτουργική έκδοση του SmallTalk - "Είχα πρόσβαση σε μια λειτουργική έκδοση του Smalltalk-80 ώστε να μπορώ να μάθω το MVC. Δεν μπορώ να πω ότι η έρευνα ήταν ενδελεχής, αλλά μου επέτρεψε να κατανοήσω ορισμένες πτυχές της λύσης που άλλες περιγραφές δεν μπορούσαν να εξηγήσουν.".

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

Ως αποτέλεσμα, πολλοί άνθρωποι θεωρούν ότι το MVC είναι ένα σχήμα ή μοτίβο (που θέτει συνεχώς το ερώτημα - ποιο από τα πολλά υπάρχοντα σχήματα είναι "σωστό" και γιατί υπάρχουν τόσα πολλά από αυτά;). Σε μια πιο προηγμένη έκδοση, ονομάζεται MVC σύνθετοςμοτίβο, δηλαδή ένας συνδυασμός πολλών προτύπων που συνεργάζονται για την υλοποίηση σύνθετων εφαρμογών (εδώ συνήθως αναφέρονται τα Observer, Strategy και Composite). Και μόνο λίγοι καταλαβαίνουν ότι το MVC είναι πρωτίστως ένα σύνολο αρχιτεκτονικών ιδεών/αρχών/προσεγγίσεων που μπορούν να εφαρμοστούν με διαφορετικούς τρόπους χρησιμοποιώντας διαφορετικά μοτίβα...

Το τελευταίο περιλαμβάνει, ειδικότερα, τον Martin Fowler. Να τι γράφει: «Το MVC αποκαλείται συχνά μοτίβο, αλλά δεν βλέπω πολύ όφελος να το σκεφτώ ως μοτίβο, καθώς περιλαμβάνει πολλές διαφορετικές ιδέες. Διαφορετικοί άνθρωποι διαβάζουν για το MVC σε διαφορετικές πηγές και παίρνουν διαφορετικές ιδέες από εκεί, αλλά τους αποκαλούν το ίδιο - "MVC". Αυτό οδηγεί σε μεγάλη σύγχυση και χρησιμεύει επίσης ως πηγή παρεξήγησης και παρεξήγησης του MVC, σαν να το έμαθαν οι άνθρωποι μέσω ενός «σπασμένου τηλεφώνου»…. Έχω χάσει τον αριθμό των φορών που έχω δει κάτι που περιγράφεται ως MVC που δεν ήταν».[Αρχιτεκτονικές GUI]

Θα τολμούσα να προτείνω ότι ένας από τους λόγους για το «σπασμένο τηλέφωνο» είναι ότι οι περισσότερες δευτερεύουσες πηγές «πίσω από τις σκηνές» αφήνουν το πιο σημαντικό πράγμα πίσω από τη σκηνή - τις ίδιες αρχιτεκτονικές ιδέες που τέθηκαν στο MVC από τους δημιουργούς του και τα προβλήματα που προσπάθησαν να λύσουν. Όλα όσα σας επιτρέπουν να κατανοήσετε την ουσία του MVC και να αποφύγετε έναν τεράστιο αριθμό παγίδων και λαθών. Επομένως, σε αυτό το άρθρο θέλω να μιλήσω για αυτό που συνήθως παραμένει "πίσω από τις σκηνές" - MVC από την άποψη των αρχιτεκτονικών αρχών και ιδεών που είναι ενσωματωμένες σε αυτό. Αν και θα υπάρχουν και διαγράμματα. Ή μάλλον, ας ξεκινήσουμε από αυτούς.

Πρώτα όμως οι σύνδεσμοι. Η αρχική αναφορά της Reenskaug είναι "Οι αρχικές αναφορές MVC". Αργότερα, ο Reenskaug διατύπωσε όλα αυτά πιο ξεκάθαρα και τα επισημοποίησε στο επόμενο έργο του, «The Model-View-Controller (MVC). Το παρελθόν και το παρόν του». Ίσως κάποιος ενδιαφέρεται για τη σελίδα όπου συγκεντρώνονται τα αρχεία του Renskaug σχετικά με εκείνη την περίοδο, με τα σχόλιά του - MVC XEROX PARC 1978-79.

Η ήδη αναφερθείσα πρώτη δημοσίευση για το MVC στη γλώσσα SmallTalk-80 από τους προγραμματιστές μόνο σε βελτιωμένη ποιότητα "A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System" (Glenn Krasner και Stephen Pope). Μια καλή προσθήκη είναι επίσης το άρθρο «Applications Programming in Smalltalk-80. How to use Model-View-Controller» (ο συγγραφέας SteveBurbeck συμμετείχε στην ανάπτυξη του μεταγλωττιστή SmallTalk για την IBM που βασίζεται στο Smalltalk-80, καθώς και στην ανάπτυξη του MacApp). Λοιπόν, αν κάποιος θέλει πλήρη εμβάπτιση - "Smalltalk-80. The Interactive Programming Environment» από τη διάσημη Adele Goldberg, σε συζητήσεις με την οποία η Reenskaug δημιούργησε τους όρους Model, View, Controller.

Σχήματα MVC

Για να καταστεί σαφές για τι πράγμα μιλάμε και ποιο είναι το πρόβλημα, ας δούμε πρώτα τα πιο τυπικά «σχήματα» MVC. Αυτό είναι σημαντικό γιατί συχνά δεν δίνονται επεξηγήσεις για τα διαγράμματα και συμβαίνει επίσης να δανείζονται ορισμοί από ένα μέρος και διαγράμματα από άλλο. Ως αποτέλεσμα, μπορείτε να βρείτε τις ίδιες περιγραφές MVC με εντελώς διαφορετικά διαγράμματα, κάτι που προκαλεί μεγάλη σύγχυση.

Έτσι, παρά το γεγονός ότι το MVC ερμηνεύεται και απεικονίζεται πολύ διαφορετικά, σε όλη αυτή την ποικιλομορφία είναι ακόμα δυνατό να εντοπιστεί ένας κοινός «πυρήνας». Το κοινό είναι ότι παντού μιλούν για συγκεκριμένα τρία μέρη - Μοντέλο, Προβολή και Ελεγκτή, τα οποία συνδέονται μεταξύ τους με έναν συγκεκριμένο τρόπο, δηλαδή:

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

Η προβολή εμφανίζει το μοντέλο. Αυτό σημαίνει ότι πρέπει με κάποιο τρόπο να λάβει από αυτό τα δεδομένα που είναι απαραίτητα για εμφάνιση. Οι πιο συνηθισμένες είναι οι ακόλουθες δύο επιλογές: 1) Ενεργή προβολή, το οποίο γνωρίζει για το Μοντέλο και παίρνει τα απαραίτητα δεδομένα από αυτό. 2) Παθητική προβολή, στην οποία παρέχονται δεδομένα από τον Ελεγκτή. Σε αυτήν την περίπτωση, η Προβολή δεν συνδέεται με κανέναν τρόπο με το Μοντέλο.




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

1. Το χειριστήριο είναι ίσως το πιο αμφιλεγόμενο στοιχείο. Ωστόσο, το κοινό είναι ότι ο Ελεγκτής γνωρίζει πάντα το Μοντέλο και μπορεί να το αλλάξει (συνήθως ως αποτέλεσμα ενεργειών του χρήστη).

Μπορεί επίσης να διαχειριστεί τις Προβολές/Προβολές (ειδικά αν υπάρχουν πολλές από αυτές) και κατά συνέπεια να γνωρίζει για τις Προβολές, αλλά αυτό δεν είναι απαραίτητο.

Από εδώ παίρνουμε τα βασικά (μέγιστα απλοποιημένα) διαγράμματα των δύο πιο κοινών ποικιλιών MVC. Η διασταυρούμενη γραμμή υποδεικνύει μια προαιρετική σύνδεση μεταξύ του ελεγκτή και της προβολής.

Αυτό είναι το βασικό διάγραμμα του Fowler: "Βασικές συνδέσεις μεταξύ Μοντέλου, Προβολής και Ελεγκτή. (Τις αποκαλώ βασικές γιατί στην πραγματικότητα η προβολή και ο ελεγκτής μπορούν να συνδεθούν απευθείας μεταξύ τους. Ωστόσο, οι προγραμματιστές γενικά δεν χρησιμοποιούν αυτήν τη σύνδεση. ) ":

Περαιτέρω. Το μοντέλο, όπως και η προβολή, μπορεί επίσης να είναι παθητικό ή ενεργό. Παθητικό μοντέλοδεν έχει καμία επίδραση ούτε στην προβολή ούτε στον ελεγκτή. Σε αυτήν την περίπτωση, όλες οι αλλαγές στο Μοντέλο παρακολουθούνται από τον Ελεγκτή και είναι επίσης υπεύθυνος για την επανασχεδίαση της Προβολής όταν είναι απαραίτητο.

Αλλά συνήθως, με τον όρο MVC εξακολουθούν να εννοούν την επιλογή με Ενεργό μοντέλο.

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

Δείγμα Παρατηρητήςεπιτρέπει στο Μοντέλο, αφενός, να ενημερώνει την Προβολή ή τον Ελεγκτή ότι έχουν συμβεί αλλαγές σε αυτό και, αφετέρου, να μην «γνωρίζει» τίποτα για αυτά (εκτός από το γεγονός ότι εφαρμόζουν μια συγκεκριμένη διεπαφή «συνδρομητή» ) και ως εκ τούτου να παραμείνουν ανεξάρτητοι. Ονομάζεται αδύναμο δέσιμοκαι θεωρείται το δεύτερο βασικό σημείο του MVC.

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

Έτσι, τα πιο προηγμένα "διαγράμματα MVC" θα μοιάζουν με αυτό:

Σχόλιο: Υπάρχουν συγγραφείς που δίνουν μια εντελώς διαφορετική έννοια στους όρους Παθητικά και Ενεργά μοντέλα. Δηλαδή, αυτό που συνήθως ονομάζεται Thin Model (ένα μοντέλο που περιέχει αποκλειστικά δεδομένα) και Thick Model (ένα πλήρες μοντέλο που περιέχει όλη την επιχειρηματική λογική της εφαρμογής).

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

Σχόλιο:πρέπει να έχετε κατά νου ότι η επιλογή με Παθητική όψη, όταν η προβολή δεν είναι σε καμία περίπτωση συνδεδεμένη με το μοντέλο και τα δεδομένα για εμφάνιση παρέχονται σε αυτήν από τον Ελεγκτή, μερικές φορές ονομάζεται MVC και μερικές φορές χωρίζεται σε ξεχωριστή ποικιλία - MVP και στη συνέχεια ο ελεγκτής μετονομάζεται σε Δωρητής.

Για να επεξηγήσουμε όλα τα παραπάνω, εδώ είναι μερικά διαγράμματα "από το Διαδίκτυο" (ελπίζω να έχει γίνει πιο σαφές γιατί είναι τόσο διαφορετικά):

Και τώρα το πιο σημαντικό - πώς χρησιμοποιούνται, τι σημαίνουν και σε τι αντιστοιχούν τα μοντέλα προβολής και ελεγκτή κατά τη σύνταξη εφαρμογών;

Εδώ μπορούμε να διακρίνουμε δύο ριζικά διαφορετικές προσεγγίσεις, σε καθεμία από τις οποίες το Model, το View και το Controller αντιμετωπίζονται με πολύ διαφορετικούς τρόπους.

"Three-tier MVC" από τον ιστό

Η πρώτη προσέγγιση προέρχεται από τον προγραμματισμό ιστού, όπου το MVC χρησιμοποιείται ευρύτερα και επομένως αντικατοπτρίζει στο μέγιστο τα χαρακτηριστικά που είναι εγγενή στον προγραμματισμό Ιστού. Δηλαδή, η δέσμευση σε μια αρχιτεκτονική τριών επιπέδων «πελάτης-διακομιστής-βάσης δεδομένων» και η κυριαρχία των γλωσσών δέσμης ενεργειών. Ως αποτέλεσμα, τα στοιχεία MVC συνδέονται επίσημα με τρία επίπεδα αρχιτεκτονικής και αποδεικνύεται ότι:

Μοντέλο = Βάση δεδομένων
Ένα μοντέλο είναι απλώς τα δεδομένα στα οποία λειτουργεί η εφαρμογή.

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

1. Προβολή = Πελάτης(συνήθως λεπτός)
   Η προβολή είναι η διεπαφή χρήστη. Επιπλέον, η διεπαφή σε αυτήν την περίπτωση, κατά κανόνα, νοείται κυρίως ως "σχεδιασμός", απλώς ένα σύνολο γραφικών στοιχείων. Η λογική αυτής της διεπαφής, καθώς και η λογική της εργασίας με δεδομένα, μεταφέρονται στον Ελεγκτή

Έχουν ήδη γραφτεί τόσα πολλά για την ανεπάρκεια αυτής της προσέγγισης που συμπεριλήφθηκε ακόμη και στη Wikipedia (MVC. Τα πιο συνηθισμένα λάθη). Τα προβλήματα που προκύπτουν σε αυτήν την περίπτωση συζητούνται καλά και λεπτομερώς στο άρθρο, το οποίο έχει γίνει ένα είδος κλασικού "". Θα προσπαθήσω λοιπόν να συνοψίσω εν συντομία:

Η ανεξαρτησία του μοντέλου είναι κεντρική στο MVC. Εάν το Μοντέλο είναι λεπτό, δηλαδή περιέχει μόνο δεδομένα, τότε η δυνατότητα ανεξάρτητης ανάπτυξής του δεν έχει νόημα. Κατά συνέπεια, με αυτήν την προσέγγιση, το ίδιο το MVC χάνει το νόημά του.

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

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

1. Εφόσον, κατά κανόνα, δεν είναι μόνο το Μοντέλο λεπτό, αλλά και η Προβολή (χαζή προβολή ή χαζή διεπαφή - Dumb GUI, Dumb View), τότε, ως αποτέλεσμα, εκτός από όλη την επιχειρηματική λογική της εφαρμογής, η λογική για τη διαχείριση της διεπαφής χρήστη τοποθετείται επίσης στον ελεγκτή. Δηλαδή, αντί να διαχωρίζει την επιχειρηματική λογική και τη λογική παρουσίασης, αυτή η προσέγγιση έχει ως αποτέλεσμα την ανάμειξή τους.

Τυπικά λάθη: ανάμειξη επιχειρηματικής λογικής και λογικής GUI στον ελεγκτή

Τα καλά νέα είναι ότι το "web MVC", το οποίο ήταν το πιο συνηθισμένο μόλις πριν από λίγα χρόνια, βρίσκεται τώρα σε πτώση. Το κακό είναι ότι είναι ακόμα ευρέως διαδεδομένο, μόνο που τώρα όχι με εμφανή τρόπο, αλλά σε μεταμφιεσμένη μορφή. Διότι για τις φράσεις (παραθέτω): « Το μοντέλο είναι η ανταλλαγή δεδομένων με τη βάση δεδομένωνκαι ούτω καθεξής. Λογική ελεγκτή για την επεξεργασία αυτών των δεδομένων και την προετοιμασία για την προβολή«Τώρα καταψηφίζουν ενεργά», μετά άρχισαν να γράφουν:

• Ένα μοντέλο είναι δεδομένα και μέθοδοι εργασίας με αυτό
• Ελεγκτής - επεξεργάζεται τις ενέργειες χρήστη και τις πληροφορίες που έχει εισάγει

Το γεγονός είναι ότι σε μια αντικειμενοστραφή εφαρμογή δεν υπάρχουν δεδομένα, αλλά υπάρχουν πολλά αντικείμενα και καθένα από αυτά περιέχει κάποιο είδος δεδομένων και μεθόδων εργασίας με αυτό. Συμπεριλαμβανομένων των αντικειμένων πρόσβασης στη βάση δεδομένων (εάν υπάρχουν). Επομένως, όταν ο ορισμός ενός Μοντέλου ξεκινά με τη λέξη «δεδομένα», ουσιαστικά δεν έχει νόημα και συχνά σε καλυμμένη μορφή υποδηλώνει την ίδια πρόσβαση στη βάση δεδομένων. ΣΕ επεξεργασίαή ενέργειες χρήστηΣυχνά τοποθετείται η μερίδα του λέοντος της επιχειρηματικής λογικής και ως αποτέλεσμα, όλη ή σχεδόν όλη η λογική της εφαρμογής συχνά καταλήγει στον Ελεγκτή.

"Αρχιτεκτονικό MVC"

Η δεύτερη προσέγγιση είναι πολύ πιο κοντά στις αρχικές πηγές. Επομένως, ας το αναλύσουμε λεπτομερέστερα.

Ο Martin Fowler έχει απόλυτο δίκιο όταν λέει ότι το MVC δεν είναι ένα μοτίβο, αλλά ένα σύνολο αρχιτεκτονικών αρχών και ιδεών που χρησιμοποιούνται στην κατασκευή προσαρμοσμένων συστημάτων πληροφοριών (συνήθως πολύπλοκων).

Προσπαθήσαμε να συλλέξουμε και να περιγράψουμε τις αρχιτεκτονικές αρχές στο άρθρο "". Για να το θέσω πολύ συνοπτικά, η ουσία είναι η εξής: ένα σύνθετο σύστημα πρέπει να χωριστεί σε ενότητες. Επιπλέον, είναι σκόπιμο να γίνει αποσύνθεση ιεραρχικά, και οι ενότητες στις οποίες χωρίζεται το σύστημα θα πρέπει, εάν είναι δυνατόν, να είναι ανεξάρτητες ή χαλαρά συζευγμένο (Χαμηλή σύζευξη). Όσο πιο χαλαρή είναι η σύζευξη, τόσο πιο εύκολο είναι να γράψετε/καταλάβετε/επεκτείνετε/διορθώσετε το πρόγραμμα. Επομένως, ένα από τα κύρια καθήκοντα στην αποσύνθεση είναι η ελαχιστοποίηση και η αποδυνάμωση των συνδέσεων μεταξύ των εξαρτημάτων.

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

“1” Διαχωρισμός του μοντέλου τομέα εφαρμογής (business logic) από τη διεπαφή χρήστη

Η πρώτη και κύρια ιδέα του MVC είναι ότι κάθε εφαρμογή χρήστη, σε μια πρώτη προσέγγιση, μπορεί να χωριστεί σε δύο ενότητες - η μία παρέχει την κύρια λειτουργικότητα της εφαρμογής, την επιχειρηματική της λογική και η δεύτερη είναι υπεύθυνη για την αλληλεπίδραση με ο χρήστης:

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

Η εργασία της αλληλεπίδρασης με τον χρήστη τοποθετείται σε ξεχωριστή ενότητα - διεπαφή χρήστηκαι μπορεί επίσης να επιλυθεί σχετικά ανεξάρτητα.

Είναι το μοντέλο τομέα (Domain Model από τα Αγγλικά μοντέλο τομέα) μετράει Μοντέλοστο «αρχιτεκτονικό MVC» (εξ ου και ο όρος). Επομένως, είναι τόσο σημαντικό να είναι ανεξάρτητο και να μπορεί να αναπτυχθεί και να δοκιμαστεί ανεξάρτητα.

"Η βασική ιδέα του MVC, και η βασική ιδέα όλων των πλαισίων που ακολουθούν, είναι αυτό που αποκαλώ Διαχωρισμένη Παρουσίαση. Το νόημα της Διαχωρισμένης Παρουσίασης είναι να χαράξει ένα σαφές όριο μεταξύ των αντικειμένων τομέα που αντικατοπτρίζουν τον πραγματικό κόσμο και την παρουσίασή μας Τα αντικείμενα, τα οποία είναι στοιχεία GUI στην οθόνη, πρέπει να είναι εντελώς ανεξάρτητα και να λειτουργούν χωρίς αναφορές στην παρουσίαση, πρέπει να μπορούν να υποστηρίζουν πολλαπλές προβολές, παρεμπιπτόντως, αυτή η προσέγγιση ήταν επίσης μια από τις σημαντικές πτυχές της κουλτούρας του Unix, επιτρέποντας ακόμη και σήμερα να εργάζονται σε μια ποικιλία εφαρμογών τόσο μέσω της γραμμής εντολών όσο και μέσω μιας γραφικής διεπαφής (ταυτόχρονα).- Φάουλερ

«2» Ανεξαρτησία μοντέλου και συγχρονισμός διεπαφών χρήστη λόγω του προτύπου Παρατηρητής

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

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

«3» Διαίρεση της διεπαφής χρήστη σε προβολή και ελεγκτή.

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

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

Δεδομένου ότι η διαίρεση της διεπαφής χρήστη σε Προβολή και Ελεγκτή αναφέρεται σε δεύτερο επίπεδο ιεραρχίας, είναι πολύ λιγότερο σημαντικό από την κύρια διαίρεση της εφαρμογής σε μοντέλο τομέα και διεπαφή. Πολύ συχνά (ειδικά όταν πρόκειται για απλά widget) δεν γίνεται καθόλου και χρησιμοποιείται " απλοποιημένο MVC", στο οποίο υπάρχει μόνο ένα μοντέλο και ένα μεμονωμένο στοιχείο διεπαφής χρήστη, το οποίο είναι ένα συνδυασμένο ViewController. Θα μιλήσουμε για αυτό με περισσότερες λεπτομέρειες λίγο αργότερα.

Το "Architectural MVC" φαίνεται αρκετά λογικό με την πρώτη ματιά. Αλλά μόλις προσπαθούμε να το εφαρμόσουμε όχι σε ένα φροντιστήριο τριών τάξεων αλλά σε ένα πραγματικό πρόγραμμα, ερχόμαστε αντιμέτωποι με μια σειρά προβλημάτων και ζητημάτων για τα οποία σπάνια γράφεται, αλλά είναι εξαιρετικά σημαντικά. Και δεν αφορούν μόνο τη διεπαφή χρήστη, αλλά και το ίδιο το Μοντέλο. Προτείνω λοιπόν να προσπαθήσετε να τα καταλάβετε και τελικά να «ακούσετε τον Καρούζο», δηλαδή να στραφείτε στις πρωτογενείς πηγές.

"Original MVC": Reenskaug και SmallTalk-80

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

Γενικά ΜοντέλοΕίναι ένα αντικείμενο ή πολλά αντικείμενα; Και είναι πραγματικά Μοντέλοστο "σχήμα MVC" είναι πανομοιότυπο με το μοντέλο τομέα που περιγράφει τη θεματική περιοχή και την επιχειρηματική λογική της εφαρμογής;

Ότι το Μοντέλο υλοποιεί το μοτίβο Παρατηρητήςδείχνει ξεκάθαρα ότι το Μοντέλο είναι ακριβώς ένα αντικείμενο. Αυτό υποδηλώνεται επίσης από το γεγονός ότι η Προβολή και ο Ελεγκτής πρέπει να γνωρίζουν για το Μοντέλο (για να λάβουν δεδομένα από αυτό και να κάνουν αλλαγές) και επομένως πρέπει να περιέχουν αναφορά σε αυτό. Στη συνέχεια, όμως, αν υποθέσουμε ότι με το μοντέλο εννοούμε ένα μοντέλο τομέα, καταλήγουμε πάλι στο συμπέρασμα ότι ολόκληρος ο πυρήνας της εφαρμογής καταλήγει σε ένα αντικείμενο. Μόνο που τώρα, αντί για ένα χοντρό, άσχημο Controller, έχουμε ένα χοντρό μοντέλο. Το Thick Model είναι φυσικά καλύτερο, αφού είναι ανεξάρτητο και, τουλάχιστον, δεν αναμειγνύει την επιχειρηματική λογική με τη λογική του GUI, αλλά εξακολουθεί να είναι δύσκολο να ταξινομηθεί μια τέτοια λύση ως καλή αρχιτεκτονική.

Η δεύτερη επιλογή παραμένει - το Μοντέλο είναι ένα σύνολο αντικειμένων τομέα που εφαρμόζουν από κοινού επιχειρηματική λογική. Αυτή η υπόθεση επιβεβαιώνεται από τον ίδιο τον Reenskaug: Ένα μοντέλο θα μπορούσε να είναι ένα μεμονωμένο αντικείμενο (μάλλον χωρίς ενδιαφέρον), ή θα μπορούσε να είναι κάποια δομή αντικειμένων.«Αλλά τότε το ερώτημα παραμένει ανοιχτό - ποιος εφαρμόζει το μοτίβο Παρατηρητής, πού λαμβάνει δεδομένα η Προβολή, πού στέλνει ο ελεγκτής εντολές χρήστη;

Και εδώ συναντάμε συχνά μια προσπάθεια εξαπάτησης του εαυτού μας με κάτι σαν τον ακόλουθο συλλογισμό: «ας είναι το Μοντέλο ένα σύνολο αντικειμένων τομέα, αλλά... ανάμεσα σε αυτό το σύνολο υπάρχει και ένα «αντικείμενο δεδομένων», και αυτό θα εφαρμόσει το μοτίβο του παρατηρητή, καθώς και να χρησιμεύσει ως πηγή δεδομένων για την Προβολή." Αυτό το κόλπο μπορεί να ονομαστεί «Μοντέλο μέσα σε Μοντέλο». Και στην πραγματικότητα, αυτή είναι μια άλλη «καλυμμένη» εκδοχή του γεγονότος ότι «Το μοντέλο είναι τα δεδομένα».

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

Για να καταλάβετε "πώς θα έπρεπε να είναι", προτείνω να στραφείτε ξανά στις "αρχές". Όταν ειπώθηκε ότι το σύστημα έπρεπε να χωριστεί σε ενότητες, χαλαρά συζευγμένομεταξύ μας, δεν αναφέραμε τον κύριο κανόνα που μας επιτρέπει να επιτύχουμε αυτή την πιο αδύναμη σύνδεση. Δηλαδή, οι μονάδες θα πρέπει να είναι «μαύρα κουτιά» η μία για την άλλη. Σε καμία περίπτωση δεν πρέπει μια μονάδα να έχει άμεση πρόσβαση σε αντικείμενα μιας άλλης μονάδας ή να γνωρίζει οτιδήποτε για την εσωτερική της δομή. Οι λειτουργικές μονάδες θα πρέπει να αλληλεπιδρούν μεταξύ τους μόνο σε επίπεδο αφηρημένων διεπαφών (Αρχή αντιστροφής εξάρτησης). Και η διεπαφή της μονάδας συνήθως υλοποιείται από ένα ειδικό αντικείμενο - Πρόσοψη.

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

Λοιπόν, τώρα ένα διάγραμμα από την αναφορά του Trygve Reenskaug:

Εξήγηση: Δεδομένου ότι την εποχή της δημιουργίας του MVC, οι διεπαφές των προγραμμάτων υπολογιστών βασίζονταν κυρίως σε κείμενο, δηλαδή αντιπροσώπευαν ουσιαστικά τον απλούστερο τύπο επεξεργαστή, αντί του όρου «Διασύνδεση χρήστη», που εμφανίστηκε αργότερα, ο Trygve Reenskaug χρησιμοποιεί το όρος «Editor» (συντάκτης).

Έτσι, η βασική ιδέα του MVC είναι πραγματικά ότι η εφαρμογή χρήστη χωρίζεται σε δύο ενότητες - η μία εκ των οποίων μοντελοποιεί τον τομέα και υλοποιεί την επιχειρηματική λογική ( μοντέλο τομέα), και το δεύτερο είναι υπεύθυνο για την αλληλεπίδραση με τον χρήστη ( διεπαφή χρήστη). Αλλά συγχρόνως Μοντέλοστο "σχήμα MVC" καθόλου δεν είναι πανομοιότυπο με το μοντέλο τομέα(το οποίο μπορεί να είναι αυθαίρετα πολύπλοκο και να αποτελείται από πολλά αντικείμενα), αλλά είναι ακριβώς δικό του διεπαφήΚαι πρόσοψη.

Επομένως, ούτε η προβολή ούτε ο ελεγκτής, φυσικά, θα πρέπει να γνωρίζουν πώς είναι δομημένη η λειτουργική μονάδα τομέα (μοντέλο τομέα), πού και σε ποια μορφή αποθηκεύονται τα δεδομένα εκεί και πώς ακριβώς πραγματοποιείται ο έλεγχος. Αλληλεπιδρούν μόνο με διεπαφήκαι την εφαρμογή του αντικείμενο πρόσοψης, το οποίο παρέχει όλα τα απαραίτητα δεδομένα στην απαιτούμενη μορφή και ένα βολικό σύνολο εντολών υψηλού επιπέδου για τον έλεγχο του υποσυστήματος, και επίσης εφαρμόζει το μοτίβο του Observer για ειδοποίηση σημαντικόςαλλαγές στο υποσύστημα. Και αν θέλουμε να αλλάξουμε τη βάση δεδομένων, να χρησιμοποιήσουμε το cloud ή γενικά να συλλέξουμε τα δεδομένα που χρειαζόμαστε από διάφορες πηγές στο δίκτυο... αν κάνουμε αλλαγές στην επιχειρηματική λογική της εφαρμογής, αλλά ταυτόχρονα φύγουμε από την πρόσοψη διεπαφή αμετάβλητη, τότε ούτε η προβολή ούτε ο ελεγκτής δεν θα επηρεάσουν. Έχουμε αρχιτεκτονική βιώσιμοςνα αλλάξει.

Και αν πρόκειται να σχεδιάσετε ένα διάγραμμα MVC, θα πρέπει να μοιάζει με αυτό:

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

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

Οι συγκεκριμένες υλοποιήσεις μπορεί να διαφέρουν, αλλά αυτό δεν έχει σημασία.

Μια πελατοκεντρική προσέγγιση είναι πολύ πιο κατάλληλη Η αρχή του διαχωρισμού διεπαφής (Αρχή διαχωρισμού διεπαφής) γιατί αντί για χοντρό για όλους Παρεχόμενη διεπαφήχρησιμοποιούνται πολλά λεπτά.

Αν δεν κάνω λάθος, αυτή είναι ακριβώς η προσέγγιση που χρησιμοποιείται στην αρχιτεκτονική των microservices. Εκεί, για αλληλεπίδραση με πολλές υπηρεσίες, εισήχθη η έννοια της πύλης, η οποία δεν είναι τίποτα άλλο από μια πρόσοψη - " Μια πύλη API είναι ένας διακομιστής που είναι το μοναδικό σημείο εισόδου στο σύστημα. Είναι παρόμοιο με το μοτίβο Πρόσοψης από αντικειμενοστραφή σχεδιασμό. Το API Gateway ενσωματώνει την εσωτερική αρχιτεκτονική του συστήματος και παρέχει ένα API που είναι προσαρμοσμένο σε κάθε πελάτη. «Δημιουργία Microservices: Χρήση πύλης API.

Επιπλέον, αυτή η πύλη " Αντί να παρέχει ένα ενιαίο στυλ API, η πύλη API μπορεί να εκθέσει ένα διαφορετικό API για κάθε πελάτη. είναι απαιτήσεις)"API Gateway.

Ας δούμε την πρόσοψη... Εδώ είναι η ίδια η κόλλα (κόλλα), ένα ενδιάμεσο αντικείμενο, διακομιστής μεσολάβησης, φίλτρο, προσαρμογέας... που συνδέει το μοντέλο domain και το περιβάλλον χρήστη και παρέχει τα απαραίτητα δεδομένα στην απαραίτητη/βολική μορφή.

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

Το θέμα των μοντέλων διεπαφής καλύπτεται ιδιαίτερα καλά στο άρθρο ενός από τα JavaGuru - Advanced MVC Patterns. Ο συγγραφέας τονίζει ότι τα μοντέλα δεν είναι δεδομένα, αλλά αποκλειστικά διεπαφές/ενδιάμεσα αντικείμενα/φίλτρα (Μοντέλα ως μεσολάβηση, μοντέλα ως φίλτρα), παρέχοντας εύκολη πρόσβαση σε δεδομένα που μπορούν να βρίσκονται οπουδήποτε - σε διαφορετικά μηχανήματα, σε διαφορετικές μορφές: Αυτό που οι περισσότεροι προγραμματιστές δεν σκέφτονται είναι ότι τα μοντέλα είναι απλώς διεπαφές. Δεν χρειάζεται να περιέχουν δεδομένα!.. Τα ενδιάμεσα μοντέλα επεκτείνουν την κάλυψη και σας επιτρέπουν να τα χρησιμοποιείτε ήδη υπάρχοντα δεδομέναόπου κι αν βρίσκονται”.

Λόγω του γεγονότος ότι η πρόσοψη που υπήρχε στο αρχικό MVC «χάθηκε», ο ρόλος της συχνά αναλαμβάνεται από τον ελεγκτή. Από εδώ προέρχεται η ιδέα ότι ο Ελεγκτής βρίσκεται «μεταξύ του Μοντέλου και της Προβολής», χρησιμεύει ως κόλλα μεταξύ τους και παρέχει τα δεδομένα που χρειάζεται η Προβολή.

Η ερώτηση εμφανίζεται συχνά στα φόρουμ: "Πώς διαφέρει ένας ελεγκτής από μια πρόσοψη;" Παρά την αφέλεια, αυτή η ερώτηση είναι αρκετά λογική και είναι δύσκολο να δοθεί μια λογική απάντηση σε αυτήν επειδή σε πολλά πλαίσια MVC ο ελεγκτής είναι στην πραγματικότητα μια πρόσοψη - "Μπροστινός ελεγκτής".

Γιατί είναι κακή αυτή η απόφαση; Αν εφαρμοστεί σωστά, τότε τίποτα. Αλλά αυτό είναι στη θεωρία. Αλλά στην πράξη, συχνά εμφανίζεται σύγχυση εννοιών και εννοιών και ως αποτέλεσμα, ο Front Controller, αφενός, κάνει κατάχρηση των εξουσιών του και αντ' αυτού ανάθεση εντολώναρχίζει να περιλαμβάνει εκτέλεσηεπαγγελματική λογική. Από την άλλη πλευρά, συνεχίζει να εκτελεί ταυτόχρονα τις λειτουργίες της διεπαφής χρήστη και ως αποτέλεσμα, εμφανίζεται σε αυτό το ήδη αναφερόμενο μείγμα «business logic» και «GUI logic» (που στην πραγματικότητα κάνει τον κώδικά του να μοιάζει με μια τεράστια χωματερή) .

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

Μεταξύ της διεπαφής και του μοντέλου τομέα (αντικείμενα γλώσσας SmallTalk) υπήρχε πάντα μια συγκεκριμένη ενδιάμεση κλάση/αντικείμενο που παρείχε βολική ολοκληρωμένη πρόσβαση στα αντικείμενα τομέα, τα δεδομένα και τις μεθόδους τους. Αυτά τα ενδιάμεσα αντικείμενα (που ουσιαστικά λειτουργούσαν ως προσόψεις) ήταν στην πραγματικότητα Μοντέλα στο SmallTalk-80.

Για παράδειγμα, οι ακόλουθες διεπαφές GUI χρησιμοποιήθηκαν για εργασία με κώδικα στο Smalltalk: Inspector, Browser, Workspace,…

Δείτε τι γράφει ο Glenn Krasner για τη συσκευή τους:

"Το Inspector στο σύστημα αποτελείται από δύο προβολές. Το ListView εμφανίζει μια λίστα μεταβλητών (στα αριστερά) και το TextView εμφανίζει την τιμή της επιλεγμένης μεταβλητής (στα δεξιά)... Το μοντέλο για αυτές τις προβολές είναι μια εμφάνιση του τάξη" Επιθεωρητής"...Χωριστή τάξη" Επιθεωρητής" είναι μεσολαβητήςή φίλτρονα παρέχει πρόσβαση σε οποιαδήποτε ιδιοκτησία οποιουδήποτε αντικειμένου. Χρήση ενδιάμεσων αντικειμένων μεταξύ Προβολή και " πραγματικός"Τα μοντέλα είναι ένας τυπικός τρόπος απομόνωσης της συμπεριφοράς εμφάνισης από το μοντέλο εφαρμογής...

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

Σχόλιο: Το όνομα της κλάσης διακομιστή μεσολάβησης που περιγράφει το ενδιάμεσο αντικείμενο πρόσοψης ήταν συνήθως το ίδιο με το όνομα του γραφικού στοιχείου που το εμφανίζει. Στο Inspector, το ενδιάμεσο μοντέλο ονομαζόταν " Επιθεωρητής", και για το πρόγραμμα περιήγησης, αντίστοιχα - " Πρόγραμμα περιήγησης».

Στην περίπτωση του Workspace, που ήταν μια από τις απλούστερες διεπαφές" Το μοντέλο ήταν ένα στιγμιότυπο StringHolder, το οποίο απλώς παρείχε κείμενο, δηλαδή μια συμβολοσειρά με πληροφορίες μορφοποίησης."

Στο τέλος του άρθρου του, ο Krasner παρέχει μια λίστα με τα μοντέλα (που προέρχονται από τη βασική κλάση Model) που χρησιμοποιούνται στο SmallTalk: StringHolder, Πρόγραμμα περιήγησης, Επιθεωρητής, Μοντέλο αρχείου, Εικόνισμα... Και σημειώνει επίσης ότι « τα μοντέλα ήταν σχεδόν πάντα ένα είδος κατηγορίας φίλτρων".

Αργότερα, στο VisualWorks Smalltalk, αναπτύχθηκε και εφαρμόστηκε πλήρως η ιδέα των ενδιάμεσων κατόχων. Εκεί, για πρόσβαση σε κάθε μεταβλητή που ανήκει σε αντικείμενα τομέα, χρησιμοποιείται η δική της διεπαφή και πρόσοψη - ValueModel και ValueHolder. Και, όπως μπορείτε να μαντέψετε, είναι το ValueModel που υλοποιεί το πρότυπο Παρατηρητής, ειδοποιώντας το GUI για αλλαγές που συμβαίνουν "στον τομέα".

Συνήθη λάθη: απευθείας πρόσβαση σε αντικείμενα τομέα

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

Για παράδειγμα, ένα ValueHolder είναι συνήθως απλώς ένα περιτύλιγμα γύρω από μια ήδη υπάρχουσα μεταβλητή τομέα, δεν χρειάζεται να περιέχει δεδομένα, περιέχει μια αναφορά στα δεδομένα. Να τι γράφουν: " Το ValueModel δεν χρειάζεται να αποθηκεύσει πραγματικά την τιμή επειδή αποθηκεύεται ήδη από άλλο μοντέλο" (Κατανόηση και χρήση των ValueModels).

Και εδώ είναι ένα απόσπασμα από το άρθρο Advanced MVC Patterns: " Ένα από τα πιο συνηθισμένα λάθη που κάνουν οι άνθρωποι όταν χρησιμοποιούν εξαρτήματα Swing είναι η αντιγραφή δεδομένων στα μοντέλα αυτών των στοιχείων Swing. Ο σωστός τρόπος είναι να χρησιμοποιήσετε υπάρχοντα δεδομένα, προσαρμόζοντάς τα χρησιμοποιώντας ένα φίλτρο... Θυμηθείτε: μην αντιγράφετε ποτέ δεδομένα που μπορούν εύκολα να ερμηνευτούν!".

Εξετάστε το ακόλουθο απλό παράδειγμα. Εάν ακολουθείτε τις συμβουλές του Διαδικτύου και χρησιμοποιείτε κώδικα όπως αυτός για την "προσθήκη στοιχείων σε λίστα" (λήφθηκε από το StackOverflow και Προσθήκη και αφαίρεση στοιχείου σε μια JList), τότε ακριβώς το ίδιο θα συμβεί αντιγραφήδεδομένα στο μοντέλο λίστας:

Αντικείμενα αντικείμενα; // Αντικείμενο τομέα DefaultListModel model = new DefaultListModel(); Λίστα JList = νέο JList(model); για (int i = 0; i< items.length; i++){ // КОПИРОВАНИЕ доменных данных в модель списка! model.addElement(items[i]); }

Είναι πιο σωστό, φυσικά, να χρησιμοποιείτε τα δεδομένα του πίνακα απλώς τυλίγοντάς τα στη διεπαφή ListModel (ειδικά επειδή έχει δημιουργηθεί ένα σχεδόν έτοιμο AbstractListModel για αυτούς τους σκοπούς):

// δημιουργήστε έναν προσαρμογέα πρόσοψης για δεδομένα τομέα, // που απλώς τον ερμηνεύει όπως απαιτείται ListModel model = new AbstractListModel() ( public int getSize() (return items.length;) public Object getElementAt(int index) (return items;) ) // περάστε τη δημιουργημένη πρόσοψη στη λίστα ως μοντέλο JList list = new JList(model);

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

Αντικείμενα1; Αντικείμενα2; // Αντικείμενα τομέα // μοντέλο πρόσοψης που συνδυάζει πίνακες ListModel model = new AbstractListModel() ( public int getSize() ( return items1.length + items2.length;) public Object getElementAt(int index) ( return index

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

Λοιπόν, αν θέλετε συντομία, τότε είναι καλύτερα ως εξής:

Λίστα JList = νέα JList(στοιχεία);

Σε αυτήν την περίπτωση, η ίδια η Java θα δημιουργήσει ένα περιτύλιγμα προσαρμογέα αντί να αντιγράψει.

Συνήθη λάθη: αντιγραφή δεδομένων τομέα σε ένα μοντέλο στοιχείου GUI

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

Μύθοι: Το μοντέλο στο «σχήμα MVC» είναι πανομοιότυπο με το μοντέλο και τα δεδομένα τομέα

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

Αλλά στο πλαίσιο των προτύπων και των διαγραμμάτων, το Μοντέλο είναι πρώτα και κύρια διεπαφήκαι την εφαρμογή του ενδιάμεσο αντικείμενο(πρόσοψη, προσαρμογέας, διακομιστής μεσολάβησης) που παρέχει εύκολη και ασφαλή πρόσβαση σε δεδομένα τομέα, τα οποία μπορούν να βρίσκονται οπουδήποτε. Ο Reenskaug έγραψε: μοντέλο αντικειμένου με πρόσοψη που αντανακλά το νοητικό μοντέλο του χρήστη".

Όταν το MVC παρουσιάζεται καθαρά ως «σχεδιασμός», η ύπαρξη «ενδιάμεσων μοντέλων» φαίνεται περίπλοκη και μπερδεμένη. Προκύπτουν ερωτήματα («Πώς διαφέρουν αυτά τα μοντέλα μεταξύ τους;», «Πώς να τα χρησιμοποιήσω σωστά;»), διφορούμενες ερμηνείες και πολλές ευκαιρίες για λάθη.

Αλλά αν κατανοήσετε τις αρχιτεκτονικές ιδέες που είναι εγγενείς στο MVC, τότε όλα γίνονται εξαιρετικά ξεκάθαρα: η διεπαφή χρήστη δεν έχει το δικαίωμα άμεσης πρόσβασης σε αντικείμενα μοντέλου τομέα. Αυτό σημαίνει ότι μεταξύ του μοντέλου τομέα και της διεπαφής χρήστη πρέπει να υπάρχει μια πρόσοψη/ενδιάμεσος/προσαρμογέας..., και η διεπαφή χρήστη (Προβολή και Ελεγκτής) μπορεί να αλληλεπιδράσει μόνο με αυτό. Υπάρχει μηδενική ευκαιρία να κάνετε λάθος.

Και σε γενικές γραμμές, δεν έχει σημασία ποιος όρος ονομάζεται αυτό το ενδιάμεσο αντικείμενο και τι είδους Model-View-Οποιαδήποτε ποικιλία MVC χρησιμοποιείται... Αρχίζετε να βλέπετε: ποιο πρόβλημα λύνεται, με τη βοήθεια πρότυπα και πόσο καλά ή κακώς γίνεται

Κατ 'αρχήν, αυτό το άρθρο μπορεί να συμπληρωθεί. Όπως ήδη αναφέρθηκε, η διαίρεση της διεπαφής χρήστη σε Προβολή και Ελεγκτή είναι το λιγότερο σημαντικό, ακόμη και βοηθητικό σημείο. Αλλά από την άλλη πλευρά, η διεπαφή χρήστη είναι παρούσα σε κάθε εφαρμογή χρήστη και η κατοχή μιας ιδέας για τις προσεγγίσεις και τις ιδέες που αναπτύσσονται σε αυτόν τον τομέα είναι συχνά χρήσιμη. Επιπλέον, γύρω από τον Ελεγκτή γίνεται η κύρια διαμάχη. Ως εκ τούτου, είναι πλήρως αφιερωμένο στο συγκεκριμένο θέμα.

Σήμερα θα μιλήσουμε για τον προγραμματισμό ιστού, συγκεκριμένα θα σας παρουσιάσουμε μαθήματα ASP.NET MVC 5 Γενικά, η εκμάθηση προγραμματισμού είναι μια εργασία εντός των δυνατοτήτων κάθε ατόμου, ανεξάρτητα από την εκπαίδευση και τα χόμπι του. Ο προγραμματιστής είναι ένα από τα πιο ακριβοπληρωμένα επαγγέλματα και στον σύγχρονο κόσμο είναι επίσης το πιο σχετικό. Δεν λειτουργούν μόνο οι υπολογιστές και τα smartphone σας με βάση τα προγράμματα, αλλά και σχεδόν όλες οι οικιακές συσκευές, τα συστήματα ασφαλείας στα σούπερ μάρκετ κ.λπ. Γι' αυτό, εάν θέλετε να ασχοληθείτε με την αυτο-ανάπτυξη και να μάθετε νέες δεξιότητες (για τον εαυτό σας ή για μια μελλοντική καριέρα, δεν έχει σημασία), είναι καλύτερο να επιλέξετε τον προγραμματισμό.

Σήμερα επιλέξαμε για εσάς τα καλύτερα μαθήματα ASP.NET MVC 5 Με βάση αυτό το πλαίσιο, η Microsoft αναπτύσσει διάφορες δυναμικές εφαρμογές web με διαχείριση δεδομένων. Ο πόρος που επιλέχθηκε ήταν το Udemy, η πιο δημοφιλής διαδικτυακή πλατφόρμα εκμάθησης, η οποία περιέχει 45.000+ μαθήματα και έχει 15 εκατομμύρια+ φοιτητές από όλο τον κόσμο.

ASP.NET MVC 5 Διαδικτυακά Μαθήματα

Ποια είναι τα πλεονεκτήματα των διαδικτυακών μαθημάτων ASP.NET MVC 5:
- μάθηση με ρυθμό κατάλληλο για εσάς.
— συνεχής πρόσβαση και δυνατότητα επιστροφής σε παρεξηγημένο υλικό.
— την ευκαιρία να διαβάσετε κριτικές και να επιλέξετε ένα μάθημα για τον εαυτό σας εκ των προτέρων.
- μεγάλη επιλογή, που δεν περιορίζεται από γεωγραφικά όρια.

Η επιλογή περιλαμβάνει τρία premium μαθήματα με τις υψηλότερες βαθμολογίες και θετικές κριτικές. Η πλήρης λίστα είναι διαθέσιμη.

Το καλύτερο ναΜαθήματα ASP.NET MVC 5 2017

1. Ολοκληρώστε το μάθημα ASP.NET MVC 5

Εκπαιδευτής: Mosh Hamedani, ένας οραματιστής μηχανικός λογισμικού, κατατάσσεται μεταξύ των κορυφαίων δασκάλων στο Udemy
Κόστος: $190
Αριθμός μαθητών: 16773+
Όγκος προγράμματος: 138 διαλέξεις. 7,5 ώρες
Επίπεδο προετοιμασίας (απαιτήσεις για το μάθημα): C# (παραστάσεις λάμδα σε ελάχιστο επίπεδο, LINQ); βασικές γνώσεις ανάπτυξης ιστοσελίδων (HTML, CSS, JavaScript και jQuery)

Τι θα μάθετε;
- Κατανοήστε το αρχιτεκτονικό μοτίβο MVC
— Δημιουργήστε φόρμες με επικύρωση στην πλευρά του διακομιστή και του πελάτη
— Χρησιμοποιήστε ισχυρά πρόσθετα jQuery
- Χρησιμοποιήστε το Entity για αναζήτηση και ενημέρωση δεδομένων
— Δημιουργία και ανάπτυξη εφαρμογών
— Διαχείριση εξαρτήσεων πελάτη-διακομιστή
— Εργαστείτε με το AutoMapper
— Εκτελέστε λειτουργίες CRUD
- Δημιουργήστε υπηρεσίες RESTful χρησιμοποιώντας το ASP.NET Web API
- Έλεγχος ταυτότητας και εξουσιοδότηση χρησιμοποιώντας ASP.NET Web API
— Κατανόηση και εφαρμογή βέλτιστων πρακτικών ασφάλειας
— Δημιουργία και διαμόρφωση διαμορφώσεων κατασκευής
— Δοκιμάστε το API χρησιμοποιώντας το PostMan

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

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

Το μάθημα είναι σχεδιασμένο για αρχάριους, αλλά απαιτεί γνώση C# και ανάπτυξη ιστού. Το μάθημα είναι πολύ δημοφιλές (16 χιλιάδες φοιτητές!) και έχει υψηλή βαθμολογία (4,6 μπορούν να βρεθούν μαθήματα C# και μαθήματα ανάπτυξης ιστού).

1. Έργο ASP.NET MVC 5 – CMS και καλάθι αγορών με υποστήριξη PayPal

Δάσκαλος: Vojislav Kovacevic, προγραμματιστής ιστοσελίδων με μεγάλη εμπειρία και γνώση στον τομέα της PHP, C#, ASP.NET MVC, OOP, HTML, JavaScript κ.λπ.
Κόστος: $30
Αριθμός μαθητών: 354+
Όγκος προγράμματος: 70 διαλέξεις. 9 η ώρα
Επίπεδο γνώσεων (απαιτήσεις μαθήματος): Visual Studio 2015 Community; δεξιότητες στο Visual Studio, βασικές γνώσεις C#, MVC και ανάπτυξη ιστού (προτιμάται, αλλά δεν απαιτείται)

Τι θα μάθετε;
— Εργαστείτε με το ASP.NET MVC και το Entity Framework
— Δημιουργήστε τις δικές σας εφαρμογές χρησιμοποιώντας ASP.NET MVC και Entity Framework

Αν το προηγούμενο μάθημα ήταν αφιερωμένο στα βασικά και στο θεωρητικό μέρος με μικρές πρακτικές εργασίες, τότε αυτό το μάθημα είναι εντελώς διαφορετικό από αυτό. Αυτό είναι ένα πρακτικό μάθημα για το ASP.NET MVC 5 χρησιμοποιώντας τεχνολογίες Entity Framework και Bootstrap.

Στο πρόγραμμα μαθημάτων, θα μάθετε πολλές τεχνικές και τεχνικές που μπορείτε να εφαρμόσετε για να δημιουργήσετε ιστοσελίδες χρησιμοποιώντας ASP.NET MVC και Entity Framework. Σε αντίθεση με τα δωρεάν μαθήματα, όλες οι σχετικές πληροφορίες συλλέγονται εδώ, οπότε δεν χρειάζεται να τις αναζητήσετε μόνοι σας.

1. Δημιουργία ιστότοπου με συνδρομές βάσει ASP.NET MVC 5

Δάσκαλος: Jonas Fagerberg, επαγγελματίας δάσκαλος, προγραμματιστής και σύμβουλος
Κόστος: 75 $
Αριθμός μαθητών: 354+
Όγκος προγράμματος: 239 διαλέξεις. 25,5 ώρες
Επίπεδο προετοιμασίας (απαιτήσεις για το μάθημα): βασικές γνώσεις MVC 5, HTML5 και CSS3, σίγουρη γνώση C#

Τι θα μάθετε;
— Δημιουργήστε μια πραγματική βάση δεδομένων σε κώδικα χρησιμοποιώντας το Entity Framework
— Χρησιμοποιήστε επικύρωση από την πλευρά του πελάτη και του διακομιστή
— Χρησιμοποιήστε το ASP.NET Identity για ασφάλεια
— Δημιουργήστε στυλ διεπαφής χρήστη χρησιμοποιώντας CSS3 και Bootstrap
— Δημιουργήστε σενάρια για να εγγραφείτε σε προϊόντα χρησιμοποιώντας κωδικούς εγγραφής
— Εφαρμόστε μια λειτουργία επαναφοράς κωδικού πρόσβασης
— Διαχειριστείτε τους χρήστες και τις συνδρομές τους
- Προσθήκη και τροποποίηση μοντέλων, προβολών και ελεγκτών για την εκτέλεση λειτουργιών CRUD σε βάσεις δεδομένων
- Χρησιμοποιήστε JavaScript, jQuery και Ajax για να δημιουργήσετε εξαιρετικές διεπαφές χρήστη με ασύγχρονες κλήσεις υπηρεσιών
— Δημιουργήστε ιστοσελίδες με απόκριση
— Εφαρμόστε έναν εναλλακτικό τρόπο σύνδεσης στην εφαρμογή
— Εγγραφή χρηστών στον ιστότοπο

Όπως και το προηγούμενο, αυτό είναι ένα πολύ πρακτικό μάθημα. Προϋποθέτει βασικές γνώσεις του MVC 5, επομένως, πριν ξεκινήσετε, συνιστούμε να παρακολουθήσετε το πρώτο μάθημα της επιλογής μας "Το πλήρες μάθημα ASP.NET MVC 5". Θα χρειαστείτε επίσης γνώση HTML5 και CSS3.

Κατά τη διάρκεια του μαθήματος, θα μάθετε πώς να δημιουργείτε έναν πλήρως λειτουργικό ιστότοπο με συνδρομές (συνδρομή) και δύο διεπαφές χρήστη (διαχειριστής και χρήστης) με βάση το ASP.NET MVC 5 χρησιμοποιώντας τη βάση δεδομένων Entity Framework. Όλα εξηγούνται βήμα-βήμα και δουλεύετε όλες τις ασκήσεις με τον δάσκαλο, κάνοντας τη μαθησιακή εμπειρία πιο διαδραστική.

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

Θυμηθείτε, τα διαδικτυακά μαθήματα ASP.NET MVC 5 όχι μόνο σας εξοπλίζουν με τις γνώσεις που χρειάζεστε και βελτιώνουν τις ευκαιρίες σταδιοδρομίας σας, αλλά σας εξοικονομούν χρόνο και χρήμα. Επιλέξτε μόνο τα καλύτερα με το InBenefit και το Udemy!

Ο Αλέξανδρος είναι ο ιδρυτής του έργου του ιστότοπου «Web Laboratory of Success», που δημιουργήθηκε για να υποστηρίξει τους αρχάριους και συνεχιζόμενους επιχειρηματίες του Διαδικτύου. Κύρια ενασχόληση: προώθηση επιχειρήσεων (συμπεριλαμβανομένων των ηλεκτρονικών καταστημάτων) μέσω του Facebook και του Google Adwords. Κύριο χόμπι: δημιουργία εσόδων από ιστότοπους μέσω εργαλείων μάρκετινγκ συνεργατών και Google Adsense. Προσωπικά επιβεβαιωμένα αρχεία: 3 εκατομμύρια επισκέπτες ιστολογίου το μήνα.

Το μάθημα εισάγει τις δυνατότητες δημιουργίας μιας διαδικτυακής εφαρμογής χρησιμοποιώντας ASP.NET MVCαπό το .NET Framework 4.5., με δυνατότητα βελτίωσης της απόδοσης και της επεκτασιμότητας των αναπτυγμένων εφαρμογών Web. Δίνεται μεγάλη προσοχή στη σύγκριση των τεχνολογιών ASP.NET MVC και ASP.NET Web Forms και των κριτηρίων για την επιλογή μιας ή άλλης τεχνολογίας.

Η επιτυχής ολοκλήρωση αυτού του μαθήματος θα επιτρέψει στους ειδικούς να:

• Περιγράψτε τις κύριες τεχνολογίες της Microsoft στον τομέα της ανάπτυξης ιστοσελίδων και επιλέξτε τις καταλληλότερες για να λύσετε τα προβλήματά σας.
• Σχεδιάστε διαδικτυακές εφαρμογές που πληρούν διάφορες απαιτήσεις.
• Δημιουργήστε μοντέλα προτύπων MVC και εφαρμόστε επιχειρηματική λογική σε αυτά τα μοντέλα.
• Δημιουργήστε ελεγκτές εφαρμογών MVC που αλληλεπιδρούν με χρήστες, μοντέλα και προβολές.
• Δημιουργήστε προβολές εφαρμογών MVC για εμφάνιση και επεξεργασία δεδομένων, καθώς και για αλληλεπίδραση με μοντέλα και ελεγκτές.
• Δημιουργήστε δοκιμές μονάδας και χρησιμοποιήστε εργαλεία εντοπισμού σφαλμάτων του Visual Studio 2012 κατά την ανάπτυξη εφαρμογών Ιστού.
• Δημιουργήστε εφαρμογές ιστού που χρησιμοποιούν διευθύνσεις URL αναγνώσιμες από τον άνθρωπο.
• Χρησιμοποιήστε μια ενιαία διεπαφή και στυλ στην εφαρμογή MVC.
• Επιταχύνετε την αλληλεπίδραση των χρηστών με προσωρινή αποθήκευση και μερική ανανέωση σελίδων.
• Δημιουργήστε κώδικα πελάτη σε JavaScript χρησιμοποιώντας τη βιβλιοθήκη jQuery.
• Δημιουργήστε ασφαλείς εφαρμογές MVC.
• Χρησιμοποιήστε τις υπηρεσίες web των Windows Azure από την εφαρμογή MVC.
• Αναπτύξτε εφαρμογές MVC.

Σκοπός του μαθήματος

Διαμόρφωση γνώσεων και δεξιοτήτων για τη δημιουργία εφαρμογών Web με χρήση ASP.NET MVC από το .NET Framework 4.5.

Το κοινό-στόχος

Έμπειροι προγραμματιστές ιστούμε εμπειρία στη δημιουργία εφαρμογών με χρήση του Visual Studio.

Απαραίτητη προετοιμασία

• Μάθημα 10267 "Εισαγωγή στην ανάπτυξη εφαρμογών Web με χρήση του Microsoft Visual Studio 2010" ή ισοδύναμη εκπαίδευση.
• Μάθημα HTML και CSS. Επίπεδο 1. Δημιουργία ιστοσελίδων σύμφωνα με τα πρότυπα του W3C και μετάβαση σε HTML 5 και CSS 3.

1. Επισκόπηση ASP.NET MVC 4

• Ανασκόπηση των τεχνολογιών web της Microsoft.
• Επισκόπηση ASP.NET 4.5.
• Εισαγωγή στο ASP.NET MVC 4.

2. Σχεδιασμός μιας διαδικτυακής εφαρμογής ASP.NET MVC 4.

• Μοντέλα αρχιτεκτονικού σχεδιασμού.
• Αρχιτεκτονικός σχεδιασμός Ελεγκτών.
• Αρχιτεκτονικός Σχεδιασμός Απόψεων.
• Αρχιτεκτονικός σχεδιασμός της εφαρμογής.

3. Ανάπτυξη μοντέλων ASP.NET MVC 4.

• Δημιουργία MVC Models (Models).
• Εργασία με δεδομένα.

4. Ανάπτυξη ελεγκτών ASP.NET MVC 4.

• Δημιουργία Ελεγκτών και τις Ενέργειές τους.
• Δημιουργία φίλτρων ενεργειών για μεθόδους.

5. Ανάπτυξη ASP.NET MVC 4 Views.

• Δημιουργία προβολών χρησιμοποιώντας τη μηχανή Razor.
• Χρήση βοηθών HTML.
• Επαναχρησιμοποίηση κώδικα στις Προβολές.

6. Δοκιμή και εντοπισμός σφαλμάτων εφαρμογών web ASP.NET MVC 4.

• Δημιουργία δοκιμών μονάδας.
• Διαμόρφωση χειρισμού εξαιρέσεων.

7. Δόμηση εφαρμογών web ASP.NET MVC 4.

• Διαμόρφωση προτύπων URL.
• Δημιουργία στοιχείων ελέγχου πλοήγησης.

8. Εφαρμογή στυλ στην εφαρμογή web ASP.NET MVC 4.

• Χρήση προτύπων προβολής.
• Εφαρμογή στυλ CSS σε μια εφαρμογή MVC.
• Δημιουργία μιας ανταποκρινόμενης διεπαφής χρήστη.

9. Δημιουργία διαδραστικών σελίδων στην εφαρμογή web ASP.NET MVC 4.

• Χρήση AJAX και μερική ανανέωση σελίδας.
• Στρατηγική προσωρινής αποθήκευσης.

10. Χρήση JavaScript και jQuery για τη δημιουργία διαδραστικών σελίδων.

• Τοποθέτηση και εκτέλεση JavaScript στη σελίδα.
• Χρήση jQuery και jQueryUI.

11. Περιορισμός πρόσβασης στην εφαρμογή web ASP.NET MVC 4.

• Έλεγχος ταυτότητας και εξουσιοδότηση.
• Ανάθεση ρόλων.

12. Ασφάλεια στην εφαρμογή web ASP.NET MVC 4.

• Δημιουργία αξιόπιστων τοποθεσιών.
• Κατάσταση αποταμίευσης.

13. Χρήση υπηρεσιών web των Windows Azure σε μια εφαρμογή web ASP.NET MVC 4.

• Εισαγωγή στο Windows Azure.
• Σχεδιασμός και υλοποίηση υπηρεσιών web Windows Azure.
• Χρήση υπηρεσιών web των Windows Azure σε μια εφαρμογή Ιστού.

14. Υλοποίηση WebAPI σε web εφαρμογή ASP.NET MVC 4.

• Ανάπτυξη WebAPI.
• Χρήση WebAPI σε εφαρμογές για κινητά και web.

15. Επεξεργασία αιτημάτων σε εφαρμογή web ASP.NET MVC 4.

• Χρήση μονάδων HTTP και χειριστών.
• Χρήση Web Sockets.

16. Ανάπτυξη της εφαρμογής web ASP.NET MVC 4.

• Ανάπτυξη μιας διαδικτυακής εφαρμογής.
• Ανάπτυξη μιας εφαρμογής MVC 4.

Έγγραφο που ελήφθη

Πιστοποιητικόσχετικά με την προχωρημένη εκπαίδευση ή Πιστοποιητικό.(Ανάλογα με την κατηγορία των ακροατών και τη συνολική διάρκεια του προγράμματος)