GUI Αρχιτεκτονικές

0

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

Graphical user interfaces έχουν γίνει ένα οικείο μέρος του λογισμικού μας τοπίο, τόσο ως χρήστες και ως προγραμματιστές. Κοιτάζοντας από ένα σχέδιο προοπτικής αντιπροσωπεύουν ένα συγκεκριμένο σύνολο προβλήματα στο σχεδιασμό του συστήματος – προβλήματα που οδήγησαν σε μια σειρά από διαφορετικές αλλά παρόμοιες λύσεις.

Το ενδιαφέρον μου είναι να εντοπιστούν τα κοινά και χρήσιμα σχέδια για προγραμματιστές εφαρμογών για χρήση σε εμπλουτισμένου προγράμματος-πελάτη ανάπτυξης. Έχω δει διάφορα σχέδια σε σχέδιο σχόλια και, επίσης, τα διάφορα σχέδια που έχουν γραφτεί σε ένα πιο μόνιμο τρόπο. Μέσα σε αυτά τα σχέδια είναι χρήσιμα σχέδια, αλλά η περιγραφή τους είναι συχνά δεν είναι εύκολο. Πάρτε Model-View-Controller ως παράδειγμα. Είναι συχνά αναφέρεται ως ένα σχέδιο, αλλά δεν το βρίσκω τρομερά χρήσιμο να σκεφτείτε από το ως ένα σχέδιο, επειδή περιέχει αρκετές διαφορετικές ιδέες. Διαφορετικοί άνθρωποι ανάγνωση για MVC σε διαφορετικά μέρη λαμβάνουν διαφορετικές ιδέες και να τις περιγράψω ως “MVC’. Αν αυτό δεν προκαλέσει αρκετή σύγχυση σας πάρει στη συνέχεια την επίδραση της παρανοήσεις του MVC που αναπτύσσουν μέσα από ένα σύστημα Chinese whispers.

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

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

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

Μορφές και τους Ελέγχους

Θα ξεκινήσω αυτή την εξερεύνηση με μια αρχιτεκτονική που είναι τόσο απλή και γνωστή. Δεν έχει ένα κοινό όνομα, τόσο για τους σκοπούς αυτού του δοκιμίου θα το ονομάσω “Μορφές και Ελέγχους”. Είναι γνωστή αυτή η αρχιτεκτονική γιατί ήταν το μόνο που ενθαρρύνεται από client-server περιβάλλοντα ανάπτυξης στην δεκαετία του 90 – εργαλεία όπως η Visual Basic, Delphi, και Powerbuilder. Είναι εξακολουθεί να χρησιμοποιείται συχνά, αν και, επίσης, συχνά διασύρεται από τον σχεδιασμό geeks σαν κι εμένα.

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

Για την παρακολούθηση παγωτού μας υγείας, η κυβέρνηση έχει δημιουργήσει σταθμούς παρακολούθησης σε όλη τη Νέα Αγγλία μέλη. Τη χρήση πολύπλοκων ατμοσφαιρικών μοντέλων, το τμήμα θέτει ως στόχο για κάθε σταθμό παρακολούθησης. Κάθε τόσο συχνά, το προσωπικό να πάει έξω σε μια αξιολόγηση που θα πάνε σε διάφορους σταθμούς και σημειώστε το πραγματικό παγωτό οι συγκεντρώσεις σωματιδίων. Αυτό το UI σας επιτρέπει να επιλέξετε ένα σταθμό και να πληκτρολογήσετε την ημερομηνία και την πραγματική αξία. Το σύστημα υπολογίζει και εμφανίζει την απόκλιση από το στόχο. Το σύστημα επισημαίνει η διακύμανση στο κόκκινο, όταν είναι 10% ή περισσότερο κάτω από τον στόχο, ή με πράσινο χρώμα, όταν το 5% ή περισσότερο πάνω από το στόχο.

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

Η φόρμα περιέχει δύο κύριες αρμοδιότητες:

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

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

Οι έλεγχοι εμφάνιση δεδομένων – σε αυτή την περίπτωση για το διάβασμα. Αυτά τα δεδομένα θα είναι σχεδόν πάντα να έρθει από κάπου αλλού, σε αυτή την περίπτωση ας υποθέσουμε ότι μια βάση δεδομένων SQL, όπως είναι το περιβάλλον που οι περισσότερες από αυτές τις client-server εργαλεία υποθέσουμε. Στις περισσότερες περιπτώσεις υπάρχουν τρία αντίγραφα των δεδομένων που συμμετέχουν:

Ένα αντίγραφο των δεδομένων που βρίσκεται στην ίδια τη βάση δεδομένων. Αυτό το αντίγραφο είναι η διαχρονική καταγραφή των δεδομένων, και το λέω εγγραφή μέλους. Η εγγραφή μέλους είναι συνήθως από κοινού και ορατή σε πολλούς ανθρώπους μέσω διαφόρων μηχανισμών.
Ένα επιπλέον αντίγραφο βρίσκεται μέσα στη μνήμη Σύνολα Ρεκόρ μέσα από την εφαρμογή. Πιο client-server περιβάλλοντα που παρέχονται εργαλεία που έκανε αυτό το εύκολο να το κάνουμε. Αυτά τα δεδομένα ήταν σχετική μόνο για το συγκεκριμένο session μεταξύ της εφαρμογής και της βάσης δεδομένων, και το λέω με την κατάσταση λειτουργίας. Ουσιαστικά αυτό αποτελεί μια προσωρινή, τοπική έκδοση των δεδομένων που ο χρήστης δουλεύει μέχρι να αποθηκεύσετε ή να δεσμευτούν, πίσω στην βάση δεδομένων – στο οποίο συγχωνεύεται με την εγγραφή μέλους. Δεν θα ανησυχείτε για τα θέματα που αφορούν τον συντονισμό καταγραφεί με την κατάσταση λειτουργίας και εδώ: πήγα σε διάφορες τεχνικές [Σ της ΕΑΑ].
Το τελικό αντίγραφο βρίσκεται μέσα στο GUI συστατικά τους. Αυτό, αυστηρά, είναι τα στοιχεία που βλέπουν στην οθόνη, ως εκ τούτου, καλώ την κατάσταση της οθόνης. Είναι σημαντικό να το UI πώς κατάσταση της οθόνης και της κατάστασης περιόδου λειτουργίας παραμένουν συγχρονισμένα.

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

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

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

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

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

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

Υπάρχουν διάφοροι τρόποι για να πάρει αυτό το είδος των πράγμα που πρέπει να λειτουργήσει – το κοινό για client-server εργαλειοθήκες ήταν η αντίληψη των γεγονότων. Κάθε στοιχείο ελέγχου είχε μια λίστα με γεγονότα που θα μπορούσαν να μεγαλώσουν. Οποιοδήποτε εξωτερικό αντικείμενο θα μπορούσε να πει ένα στοιχείο ελέγχου που ενδιαφέρεται για μια εκδήλωση – στην οποία περίπτωση ο έλεγχος θα πάρω αυτό το εξωτερικό αντικείμενο, όταν η εκδήλωση είχε τεθεί. Ουσιαστικά είναι μια αναδιατύπωση του Παρατηρητή μοτίβο, όπου η μορφή είναι παρατηρώντας τον έλεγχο. Το πλαίσιο, συνήθως, παρέχεται ένας μηχανισμός όπου ο προγραμματιστής του μορφή θα μπορούσε να γράψει κώδικα σε μια υπορουτίνα που θα γίνει επίκληση όταν συνέβη το γεγονός. Πώς ακριβώς το link μεταξύ γεγονότος και τη ρουτίνα κυμάνθηκε μεταξύ πλατφόρμας και έχει σημασία για την παρούσα συζήτηση, το θέμα είναι ότι υπήρχε κάποιος μηχανισμός για να το κάνει να συμβεί.

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

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

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

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

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

Μπορούμε να συνοψίσουμε την αρχιτεκτονική με μερικές ατάκες:

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

Model View Controller

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

Όπως βλέπουμε στο MVC είναι σημαντικό να θυμόμαστε ότι αυτή ήταν μία από τις πρώτες προσπάθειες για να κάνουμε σοβαρή UI λειτουργήσει σε οποιοδήποτε είδος της κλίμακας. Graphical User Interfaces δεν ήταν ακριβώς κοινό στη δεκαετία του 70. Τα Έντυπα και να Ελέγχει το μοντέλο που σας περιέγραψα ήρθε μετά MVC – έχω το περιέγραψε πρώτος, επειδή είναι πιο απλό, όχι πάντα με καλό τρόπο. Και πάλι θα συζητήσουμε Smalltalk 80 MVC χρησιμοποιώντας την εκτίμηση παράδειγμα – αλλά θα πρέπει να γνωρίζετε ότι παίρνω λίγα ελευθεριών με τις πραγματικές λεπτομέρειες της Smalltalk 80 για να το κάνετε αυτό για αρχή ήταν μια μονόχρωμη σύστημα.

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

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

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

Η παρουσίαση μέρους του MVC είναι κατασκευασμένο από τα υπόλοιπα δύο στοιχεία: view και controller. Ο ελεγκτής είναι δουλειά του είναι να δέχεται την είσοδο του χρήστη και να καταλάβω τι να κάνει με αυτό.

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

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

Η διαμόρφωση του πεδίου κειμένου προέρχεται από δίνω ένα link με το μοντέλο, την ανάγνωση, και να του λέει τι ποια μέθοδο να επικαλεστεί όταν το κείμενο αλλάζει. Αυτό έχει οριστεί σε “#πραγματική: “όταν η οθόνη είναι προετοιμασία (ένας κορυφαίος” # ” δείχνει ένα σύμβολο, ή φυλακίστηκαν string, Smalltalk). Το κείμενο τομέα ελεγκτής, στη συνέχεια, κάνει μια αντανακλαστική επίκληση της εν λόγω μεθόδου στην ανάγνωση για να κάνετε την αλλαγή. Ουσιαστικά αυτό είναι το ίδιο μηχανισμό όπως συμβαίνει για σύνδεση Δεδομένων, ο έλεγχος συνδέεται με το υποκείμενο αντικείμενο (γραμμή) και ποια μέθοδος (στήλη) που εκμεταλλεύεται.

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

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

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

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

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

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

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

Ενώ οι διαφορετικές προσεγγίσεις για το συγχρονισμό είναι ιδιαίτερα αισθητή από κοιτάζοντας το διάγραμμα ακολουθίας, το πιο σημαντικό, και πιο σημαντικό, η διαφορά είναι MVC χρήση Διαχωρίζονται Παρουσίαση. Τον υπολογισμό της απόκλισης μεταξύ των πραγματικών και στόχος είναι το domain συμπεριφορά, δεν είναι τίποτα να κάνει με το UI. Ως αποτέλεσμα εξής Χωρίζονται Παρουσίαση λέει ότι θα πρέπει το domain στρώμα του συστήματος – το οποίο είναι ακριβώς ό, τι η ανάγνωση αντικείμενο που αντιπροσωπεύει. Όταν εξετάζουμε την ανάγνωση αντικείμενο, η διακύμανση χαρακτηριστικό καθιστά την πλήρη έννοια του όρου, χωρίς καμία έννοια του user interface.

Σε αυτό το σημείο, ωστόσο, μπορούμε να αρχίσουμε να εξετάσουμε κάποιες επιπλοκές. Υπάρχουν δύο περιοχές όπου έχω χάσει πάνω από κάποια δύσκολη σημεία που παίρνουν το δρόμο της MVC θεωρία. Το πρώτο πρόβλημα είναι να ασχοληθεί με τη ρύθμιση το χρώμα της διασποράς. Αυτό δεν θα πρέπει να χωρέσει σε ένα αντικείμενο του τομέα, όπως το χρώμα με το οποίο θα εμφανίσει μια αξία, δεν είναι μέρος του τομέα. Το πρώτο βήμα είναι να συνειδητοποιήσουμε ότι ένα μέρος της λογικής είναι domain λογική. Ό, τι κάνουμε εδώ είναι να κάνει μια ποιοτική δήλωση σχετικά με τη διακύμανση, την οποία θα μπορούσαμε να ορίσουμε ως καλή (πάνω από περισσότερο από 5%), κακά (κάτω από περισσότερο από 10%), και το κανονικό (το υπόλοιπο). Της αξιολόγησης αυτής είναι ασφαλώς τομέα γλώσσα, χαρτογράφηση ότι τα χρώματα και να αλλοιωθεί η διακύμανση πεδίο προβολή λογική. Το πρόβλημα έγκειται στο πού θα βάλουμε την άποψη αυτή η λογική – δεν είναι μέρος του προτύπου μας πεδίο κειμένου.

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

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

Ένας τρόπος θα προτιμούσα να είναι να οικοδομήσουμε ένα νέο είδος του ελέγχου UI. Ουσιαστικά αυτό που χρειαζόμαστε είναι ένα UI ελέγχου που ζητά το domain για μια ποιοτική αξία, τη συγκρίνει με κάποια εσωτερική πίνακα τιμών και χρώματα, και ορίζει το χρώμα της γραμματοσειράς ανάλογα. Από τον πίνακα και το μήνυμα να ρωτήσω το αντικείμενο του τομέα θα καθοριστεί από την αξιολόγηση άποψη, όπως είναι η συγκέντρωση, όπως ορίζει η πτυχή για το πεδίο ελέγχου. Αυτή η προσέγγιση θα μπορούσε να λειτουργήσει πολύ καλά, αν μπορώ εύκολα να υποκατηγορία πεδίο κειμένου για να προσθέσετε τα επιπλέον συμπεριφορά. Αυτό προφανώς εξαρτάται από το πόσο καλά τα στοιχεία σχεδιάζονται για να επιτρέψουν σε sub-classing – Smalltalk κάνει πολύ εύκολο – άλλα περιβάλλοντα μπορεί να το κάνει πιο δύσκολο.

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

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

Η Παρουσίαση Μοντέλο λειτουργεί καλά και για μια άλλη παρουσίαση πρόβλημα λογικής – παρουσίαση κράτος. Η βασική MVC έννοια προϋποθέτει ότι το κράτος από την άποψη που μπορεί να προέρχεται από το κράτος του μοντέλου. Σε αυτή την περίπτωση πώς θα καταλάβω ποιο σταθμό είναι επιλεγμένο στη λίστα κουτί; Η Παρουσίαση του Μοντέλου λύνει αυτό για μας δίνοντάς μας ένα μέρος για να θέσει αυτό το είδος του κράτους. Ένα παρόμοιο πρόβλημα παρουσιάζεται αν πρέπει να αποθηκεύσετε τα κουμπιά που είναι ενεργοποιημένη μόνο εάν τα δεδομένα έχουν αλλάξει – και πάλι ότι το κράτος μας αλληλεπίδραση με το μοντέλο, όχι το ίδιο το μοντέλο.

Έτσι, τώρα νομίζω ότι ήρθε η ώρα για κάποια συνθηματολογία στο MVC.

Κάνει μια ισχυρή διαχωρισμός μεταξύ παρουσίαση (view & controller) και τομέα (πρότυπο) που Διαχωρίζεται Παρουσίαση.
Χωρίστε GUI widgets σε έναν ελεγκτή (για την αντίδραση των χρηστών ερέθισμα) και την προβολή (για την εμφάνιση της κατάστασης του μοντέλου). Ελεγκτής και να το δείτε θα πρέπει (συνήθως) δεν επικοινωνούν απευθείας, αλλά μέσα από το μοντέλο.
Έχουν θέα (και ελεγκτές) να τηρούν το πρότυπο για να επιτρέπουν πολλαπλά widgets για την ενημέρωση, χωρίς να χρειάζεται να επικοινωνούν άμεσα – Παρατηρητή Συγχρονισμού.

VisualWorks Εφαρμογή Του Μοντέλου

Όπως συζητήσαμε παραπάνω, Smalltalk 80 MVC ήταν πολύ μεγάλη επιρροή και είχε μερικά εξαιρετικά χαρακτηριστικά, αλλά και κάποια ελαττώματα. Όπως Smalltalk, που αναπτύχθηκε στη δεκαετία του ’80 και του’ 90 αυτό οδήγησε σε σημαντικές παραλλαγές στο κλασικό μοντέλο MVC. Πράγματι θα μπορούσε να πει κανείς ότι MVC εξαφανίστηκε, αν θεωρείτε ότι η προβολή/ελεγκτής χωρισμού να είναι ένα ουσιαστικό μέρος της MVC – που το όνομά του υπονοεί.

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

Smalltalk, επίσης, κατακερματισμένη σε αυτά τα χρόνια. Οι βασικές ιδέες της Smalltalk, συμπεριλαμβανομένης της (ελάχιστα) γλώσσα ορισμού παρέμεινε η ίδια, αλλά είδαμε πολλαπλές Smalltalks ανάπτυξη με διαφορετικές βιβλιοθήκες. Από ένα UI προοπτική αυτή έγινε σημαντικό, καθώς πολλές βιβλιοθήκες άρχισαν να χρησιμοποιούν τη μητρική widgets, τα στοιχεία ελέγχου που χρησιμοποιούνται από τις Μορφές και τους Ελέγχους στυλ.

Smalltalk αναπτύχθηκε αρχικά από την Xerox Parc εργαστήρια και καλύπτουν μια ξεχωριστή εταιρεία, ParcPlace, για την αγορά και την ανάπτυξη της γλώσσας Smalltalk. ParcPlace Smalltalk ονομαζόταν VisualWorks και έκανε το σημείο του να είναι ένα cross-platform σύστημα. Πολύ πριν από την Ιάβα, μπορεί να λάβει μια Smalltalk πρόγραμμα γραμμένο σε Windows και να τρέξει αμέσως στο Solaris. Ως αποτέλεσμα VisualWorks δεν χρησιμοποιούν τη μητρική widgets και κράτησε το GUI εντελώς μέσα σε Smalltalk.

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

Βασικό στοιχείο αυτού του είδους της Smalltalk ήταν η ιδέα της στροφής ιδιότητες σε αντικείμενα. Στη συνηθισμένη μας αντίληψη των αντικειμένων με ιδιότητες πιστεύουμε ότι ένα Άτομο αντικείμενο με ιδιότητες για το όνομα και τη διεύθυνση. Αυτές οι ιδιότητες μπορεί να είναι πεδία, αλλά θα μπορούσε να είναι κάτι άλλο. Υπάρχει συνήθως μια τυποποιημένη σύμβαση για την πρόσβαση των ιδιοτήτων: στην Java θα δούμε temp = είναι αυτή.getName() και να είναι αυτή.setName(“μάρτιν”), σε C# θα temp = είναι αυτή.όνομα και να είναι αυτή.name = “μάρτιν”.

Μια Ιδιότητα του Αντικειμένου αλλάζει αυτό, έχουν την ιδιότητα να επιστρέψει ένα αντικείμενο που τυλίγει την πραγματική αξία. Έτσι, σε VisualWorks όταν ζητάμε ένα όνομα θα πάρει πίσω ένα περιτύλιγμα αντικείμενο. Μπορούμε στη συνέχεια να πάρει την πραγματική αξία ζητώντας από το περιτύλιγμα αντικειμένου για την αξία του. Έτσι την πρόσβαση σε ένα όνομα θα χρησιμοποιήσετε temp = όνομα είναι αυτή αξία και είναι αυτή όνομα τιμής: “martin”

Τοποθεσία αντικείμενα που κάνουν την αντιστοίχιση μεταξύ widgets και το μοντέλο του λίγο πιο εύκολη. Απλά πρέπει να πω το widget τι μήνυμα να στείλω για να πάρει την αντίστοιχη ιδιότητα, και το widget ξέρει να έχουν πρόσβαση σε σωστή τιμή χρησιμοποιώντας αξία και αξία:. VisualWorks ιδιοκτησία αντικείμενα επιτρέψει επίσης σε σας για να δημιουργήσει παρατηρητές με το μήνυμα onChangeSend: ένα μήνυμα: anObserver.

Δεν θα βρείτε μια κατηγορία που ονομάζεται αντικείμενο ιδιοκτησίας σε εικαστικά Έργα. Αντί να υπάρχει μια σειρά από κλάσεις που ακολούθησε την αξία/αξία:/onChangeSend: πρωτόκολλο. Η απλούστερη είναι η ValueHolder – το οποίο περιέχει μόνο την αξία του. Περισσότερα σχετικά με αυτή τη συζήτηση είναι η AspectAdaptor. Το AspectAdaptor επιτρέπεται ένα ακίνητο αντικείμενο για να τυλίξει μια ιδιότητα από ένα άλλο αντικείμενο εντελώς. Με αυτόν τον τρόπο, μπορείτε να ορίσετε μια ιδιότητα του αντικειμένου σε PersonUI τάξη που τύλιξε σε μια τοποθεσία σε ένα Άτομο αντικείμενο από κώδικα, όπως

adaptor := AspectAdaptor subject: person
adaptor forAspect: #name
adaptor onChangeSend: #redisplay to: self

Ας δούμε λοιπόν πώς η εφαρμογή του μοντέλου ταιριάζει στο τρέχον παράδειγμα μας.

Η κύρια διαφορά μεταξύ χρησιμοποιώντας μια εφαρμογή του μοντέλου και κλασικό MVC είναι ότι τώρα έχουμε μια ενδιάμεση κατηγορία μεταξύ του τομέα μοντέλο της κατηγορίας (Reader) και το widget – αυτή είναι η εφαρμογή του μοντέλου της κατηγορίας. Τα widgets δεν έχει πρόσβαση στον τομέα αντικείμενα άμεσα – το μοντέλο τους είναι η εφαρμογή του μοντέλου. Τα Widgets είναι ακόμα κατανεμημένες σε απόψεις και ελεγκτές, αλλά αν είστε οικοδόμηση νέων widgets αυτή η διάκριση δεν είναι σημαντικό.

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

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

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

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

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

Τον περιορισμό όλων αυτών, ωστόσο, είναι ότι για περισσότερο σύνθετη συμπεριφορά θα πρέπει να κατασκευαστούν ειδικά widgets και ακίνητα αντικείμενα. Ως παράδειγμα την προϋπόθεση σύνολο των αντικειμένων δεν παρέχει έναν τρόπο για να συνδέσετε το χρώμα του κειμένου της διακύμανσης του βαθμού διακύμανσης. Διαχωρίζοντας την εφαρμογή και τον τομέα μοντέλα δεν μας επιτρέπουν να διαχωρίσουμε τη λήψη αποφάσεων με το σωστό τρόπο, αλλά, στη συνέχεια, να χρησιμοποιήσετε widgets παρατηρώντας πτυχή προσαρμογείς θα χρειαστεί να κάνετε κάποιες νέες κατηγορίες. Συχνά αυτό θεωρείται πάρα πολύ δουλειά, ώστε να μπορούμε να κάνουμε αυτό πιο εύκολη, επιτρέποντας την εφαρμογή του μοντέλου για να αποκτήσετε πρόσβαση στο widgets άμεσα, όπως στο Σχήμα 11.

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

Έτσι τώρα η συνθηματολογία για την Εφαρμογή του Μοντέλου

Ακολούθησε MVC χρησιμοποιώντας Χωρίζονται Παρουσίαση και Παρατηρητής ο Συγχρονισμός.
Εισήγαγε μια ενδιάμεση εφαρμογή του μοντέλου ως ένα σπίτι για την παρουσίαση λογική και πολιτεία και μερική ανάπτυξη Παρουσίαση του Μοντέλου.
Widgets δεν παρατηρούν αντικείμενα του τομέα, άμεσα, αντί να παρατηρούν την εφαρμογή του μοντέλου.
Έκανε εκτεταμένη χρήση του Ακινήτου Αντικείμενα για να βοηθήσει να συνδέσει τα διάφορα στρώματα και να υποστηρίζει το λεπτόκοκκο συγχρονισμού χρησιμοποιώντας παρατηρητές.
Δεν ήταν η προεπιλεγμένη συμπεριφορά για την εφαρμογή του μοντέλου για να χειραγωγήσουν widgets, αλλά συνήθως γίνεται για πολύπλοκες περιπτώσεις.

Model-View-Παρουσιαστής (MVP)

MVP είναι μια αρχιτεκτονική που εμφανίστηκε για πρώτη φορά στην IBM και πιο ορατά στο Taligent κατά τη διάρκεια της δεκαετίας του 1990. Είναι πιο συχνά αναφέρεται μέσω του Potel χαρτί. Η ιδέα ήταν περαιτέρω διαδόθηκε και περιγράφεται από τους προγραμματιστές του Dolphin Smalltalk. Όπως θα δείτε οι δύο περιγραφές μην εντελώς πλέγμα, αλλά η βασική ιδέα από κάτω έχει γίνει δημοφιλής.

Για την προσέγγιση MVP θα το βρείτε χρήσιμο να σκεφτούμε μια σημαντική αναντιστοιχία μεταξύ δύο σκέλη του UI σκέψης. Από τη μία πλευρά είναι οι Μορφές και αρχιτεκτονική Ελεγκτών, που ήταν η επικρατούσα προσέγγιση στο σχεδιασμό UI, από την άλλη είναι MVC και τα παράγωγά της. Τα Έντυπα και να Ελέγχει το μοντέλο παρέχει ένα σχεδιασμό που είναι εύκολο να κατανοήσουν και να κάνει καλό διαχωρισμό μεταξύ επαναχρησιμοποιήσιμα widgets και εφαρμογή ειδικού κώδικα. Αυτό που του λείπει, και MVC έχει τόσο έντονα, Διαχωρίζεται Παρουσίαση και πράγματι, στο πλαίσιο του προγραμματισμού χρησιμοποιώντας ένα Domain Model. Βλέπω MVP ως ένα βήμα προς την ένωση αυτών των ρευμάτων, που προσπαθεί να πάρει το καλύτερο από τον καθένα.

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

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

Ο παρουσιαστής στη συνέχεια να αποφασίσει πώς να αντιδράσουν σε περίπτωση. Potel ασχολείται με αυτή την αλληλεπίδραση, κυρίως όσον αφορά δράσεις σχετικά με το μοντέλο, που κάνει από ένα σύστημα εντολές και επιλογές. Ένα χρήσιμο πράγμα που πρέπει να επισημάνω εδώ, είναι η προσέγγιση της συσκευασίας όλες οι αλλαγές στο πρότυπο σε μια εντολή – αυτό παρέχει μια καλή βάση για την παροχή undo/redo συμπεριφορά.

Ως Παρουσιαστής ενημερωμένες εκδόσεις του μοντέλου, το view ενημερώνεται από το ίδιο Παρατηρητή Συγχρονισμού προσέγγιση που MVC χρήσεις.

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

Μία από τις τροποποιήσεις σκέφτομαι MVP είναι ο βαθμός στον οποίο ο παρουσιαστής ελέγχει την widgets στην προβολή. Από τη μία πλευρά υπάρχει η περίπτωση όπου όλοι προβολή λογική είναι αριστερά στην προβολή και ο παρουσιαστής δεν συμμετέχει στη λήψη αποφάσεων για το πώς να καταστήσει το πρότυπο. Αυτό το στυλ είναι το ένα συνεπάγεται Potel. Η κατεύθυνση πίσω Bower και McGlashan ήταν αυτό που πήρα την Εποπτεία του Ελεγκτή, όπου η θέα λαβές μια καλή συμφωνία της με την άποψη της λογικής που μπορεί να περιγράφονται declaratively και ο παρουσιαστής στη συνέχεια, έρχεται για να χειριστεί πιο πολύπλοκες περιπτώσεις.

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

Πριν αντίθεση MVP με ό, τι έχω συζητήσει πριν θα πρέπει να αναφέρω ότι και οι δύο MVP χαρτιά κάνετε αυτό πάρα πολύ – αλλά όχι ακριβώς με την ίδια ερμηνεία που έχω. Potel συνεπάγεται ότι MVC ελεγκτές ήταν συνολικά συντονιστές – που δεν το βλέπω. Δελφίνι, μιλάει για θέματα MVC, αλλά από MVC έχουν το VisualWorks Εφαρμογή Διαμορφώστε το σχέδιο και όχι το κλασικό MVC αυτό που περιέγραψα (δεν τους κατηγορώ για αυτό – να προσπαθεί να πάρει πληροφορίες σχετικά με το κλασικό MVC δεν είναι εύκολο, τώρα, πόσο μάλλον τότε.)

Έτσι, τώρα είναι η ώρα για κάποιες αντιθέσεις:

Υπάρχουν προφανείς ομοιότητες μεταξύ MVP παρουσιαστές και MVC ελεγκτές, και παρουσιαστές είναι μια χαλαρή μορφή MVC ελεγκτής. Ως αποτέλεσμα, πολλά σχέδια θα ακολουθήσει ο MVP στυλ αλλά και χρήση “υπεύθυνος” ως συνώνυμο για την παρουσιάστρια. Υπάρχει ένα λογικό επιχείρημα για τη χρήση ελεγκτή γενικά, όταν μιλάμε για το χειρισμό της εισόδου του χρήστη.

Ας δούμε ένα MVP (Εποπτεία Controller) έκδοση του ice-cream οθόνη ( Εικόνα 12). Ξεκινάει πολύ το ίδιο όπως και οι Μορφές και Ελέγχου έκδοση – το πραγματικό πεδίο κειμένου δημιουργεί μια εκδήλωση, όταν το κείμενο έχει αλλάξει, ο παρουσιαστής ακούει αυτό το γεγονός και παίρνει τη νέα τιμή του πεδίου. Σε αυτό το σημείο ο παρουσιαστής ενημερώσεις την ανάγνωση αντικείμενο του τομέα, τα οποία η διακύμανση πεδίο τηρεί και ενημερώνει το κείμενο. Το τελευταίο μέρος είναι η ρύθμιση του χρώματος για τη διακύμανση τομέα, η οποία γίνεται από τον παρουσιαστή. Παίρνει την κατηγορία από την ανάγνωση και, στη συνέχεια, ενημερώνει το χρώμα της διακύμανσης τομέα.

Εδώ είναι ο MVP συνθηματολογία:

Από το χρήστη χειρονομίες παραδίδονται εκτός από τα widgets για να Επιβλέπων Ελεγκτή.
Ο παρουσιαστής συντεταγμένες αλλαγές στο domain model.
Διαφορετικές παραλλαγές του MVP λαβή προβάλετε ενημερώσεις διαφορετικά. Αυτές ποικίλλουν από τη χρήση του Παρατηρητή Συγχρονισμού για να έχει ο παρουσιαστής κάνει όλες τις ενημερώσεις με πολύ έδαφος σε-μεταξύ.

Ταπεινή Άποψη

Τα τελευταία χρόνια υπάρχει μια ισχυρή μόδας για τη γραφή μόνος-δοκιμή κώδικα. Παρά το γεγονός ότι το τελευταίο πρόσωπο για να ρωτήσω για την αίσθηση της μόδας, αυτό είναι ένα κίνημα που είμαι καλά βυθίζεται. Πολλοί από τους συναδέλφους μου είναι μεγάλοι οπαδοί του xUnit πλαίσια, αυτοματοποιημένη παλινδρόμησης εξετάσεις, Test-Driven Development, η Συνεχής Ολοκλήρωση και παρόμοιες λέξεις.

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

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

Ως αποτέλεσμα υπάρχει μια σταθερή κίνηση για το σχεδιασμό UIs με τέτοιο τρόπο που να ελαχιστοποιεί την συμπεριφορά του σε αντικείμενα που είναι δύσκολη για τη δοκιμή. Ο μάικλ Φτερά ευκρινώς συνόψισε την προσέγγιση αυτή κατά Την Ταπεινή παράθυρο Διαλόγου. Gerard Meszaros γενικευμένη αυτή την αντίληψη για την ιδέα της ένα Ταπεινό Αντικείμενο – κάθε αντικείμενο που είναι δύσκολο να δοκιμών θα πρέπει να έχουν ελάχιστη συμπεριφορά. Έτσι, αν δεν είμαστε σε θέση να το συμπεριλάβει στη δοκιμή μας suites, θα ελαχιστοποιήσετε τις πιθανότητες μια απαρατήρητα αποτυχία.

Η Ταπεινή παράθυρο Διαλόγου χαρτί χρησιμοποιεί έναν παρουσιαστή, αλλά σε ένα πολύ βαθύτερο τρόπο από την αρχική MVP. Όχι μόνο κάνει την παρουσιάστρια να αποφασίσει πώς να αντιδρούν σε συμβάντα χρηστών, χειρίζεται επίσης τον πληθυσμό των δεδομένων στο UI widgets τον εαυτό τους. Ως αποτέλεσμα, η widgets πλέον, ούτε πρέπει, προβολή του υποδείγματος, αποτελούν μια Παθητική Άποψη, χειραγωγείται από τον παρουσιαστή.

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

Το κλειδί και για τις δύο προσεγγίσεις είναι ότι από τη δοκιμή του παρουσιαστή ή με τη δοκιμή της παρουσίασης πρότυπο, μπορείτε να δοκιμάσετε περισσότερα από τον κίνδυνο του UI, χωρίς να χρειάζεται να αγγίξει το σκληρό-to-test widgets.

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

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

Μια παρόμοια trade-off που υπάρχει με την Εποπτεία των Ελεγκτών. Έχοντας την άποψη απλό αντιστοιχίσεις εισάγει κάποιο κίνδυνο, αλλά με το όφελος (όπως και με την Παρουσίαση Πρότυπο) να είναι σε θέση να καθορίσετε την απλή χαρτογράφηση declaratively. Αντιστοιχίσεις θα τείνουν να είναι μικρότερα για την Εποπτεία των Ελεγκτών από ό, τι για την Παρουσίαση Πρότυπο ως σύνθετη ενημερώσεις θα καθορίζεται από την Παρουσίαση του Μοντέλου και να χαρτογραφηθούν, ενώ την Εποπτεία Ελεγκτής θα χειριστείτε τα widgets για πολύπλοκες υποθέσεις, χωρίς οποιαδήποτε αντιστοίχιση που εμπλέκονται.
Αρχικά στο http://martinfowler.com/eaaDev/uiArchs.html