Φιλοσοφίες Εφαρμογής Προσέγγισης
προσέγγιση καταρράκτη
Η προσέγγιση του καταρράκτη για την υλοποίηση μιας εφαρμογής απαιτεί από έναν σχεδιαστή να συμβουλευτεί έναν ή περισσότερους εκπροσώπους της οργάνωσης του τελικού χρήστη και να σημειώσει όλες τις προδιαγραφές της εφαρμογής. Συνήθως, οι προδιαγραφές περιλαμβάνονται σε ένα σύνολο λειτουργικών εγγράφων ή περιπτώσεων χρήσης, γραμμένων με τέτοιο τρόπο ώστε ο τελικός χρήστης να μπορεί εύκολα να διαβάσει και να κατανοήσει τα έγγραφα.
Ο τελικός χρήστης υπογράφει αυτά τα έγγραφα και στη συνέχεια τα έγγραφα συλλέγονται από την ομάδα τεχνικής σχεδίασης που σχεδιάζει την εφαρμογή, δημιουργώντας διάφορα τεχνουργήματα όπως διαγράμματα μοντέλων τάξης, διαγράμματα κατάστασης, διαγράμματα δραστηριότητας και μοντέλα δεδομένων. Ο στόχος αυτής της φάσης είναι να γράψει τα πάντα με τόση λεπτομέρεια που ένας προγραμματιστής δεν θα δυσκολευτεί να δημιουργήσει τον απαραίτητο κώδικα. Υπάρχει επίσημη παράδοση του σχεδίου στην ομάδα ανάπτυξης και στην ομάδα δοκιμών. Μετά την παράδοση, η ομάδα ανάπτυξης ξεκινά την κωδικοποίηση και η ομάδα δοκιμής χρησιμοποιεί τον τεχνικό σχεδιασμό σε συνδυασμό με τις περιπτώσεις χρήσης για να δημιουργήσει δοκιμαστικές περιπτώσεις και σενάρια δοκιμών.
Αφού η ομάδα ανάπτυξης ολοκληρώσει την κωδικοποίηση, ο κώδικας παραδίδεται στην ομάδα δοκιμής. Η ομάδα δοκιμών εκτελεί τις δοκιμές που έχει σχεδιάσει με βάση τις απαιτήσεις και τον λεπτομερή σχεδιασμό. Τυχόν προβλήματα θα διορθωθούν από την ομάδα ανάπτυξης. Μόλις ολοκληρωθεί η διαδικασία δοκιμής και επιδιόρθωσης, η εφαρμογή παραδίδεται στον τελικό χρήστη για δοκιμή αποδοχής. Ο τελικός χρήστης πραγματοποιεί έναν τελικό έλεγχο για να διαπιστώσει εάν η εφαρμογή συμμορφώνεται με τις αρχικές απαιτήσεις. Εάν εγκριθεί, εγκρίνει το τελικό προϊόν και το έργο ολοκληρώνεται. Αφού η ομάδα ανάπτυξης ολοκληρώσει την κωδικοποίηση, ο κώδικας παραδίδεται στην ομάδα δοκιμής.
Η ομάδα δοκιμών εκτελεί τις δοκιμές που έχει σχεδιάσει με βάση τις απαιτήσεις και τον λεπτομερή σχεδιασμό. Τυχόν προβλήματα θα διορθωθούν από την ομάδα ανάπτυξης. Μόλις ολοκληρωθεί η διαδικασία δοκιμής και επιδιόρθωσης, η εφαρμογή παραδίδεται στον τελικό χρήστη για δοκιμή αποδοχής. Ο τελικός χρήστης πραγματοποιεί έναν τελικό έλεγχο για να διαπιστώσει εάν η εφαρμογή συμμορφώνεται με τις αρχικές απαιτήσεις. Εάν εγκριθεί, εγκρίνει το τελικό προϊόν και το έργο ολοκληρώνεται. Αφού η ομάδα ανάπτυξης ολοκληρώσει την κωδικοποίηση, ο κώδικας παραδίδεται στην ομάδα δοκιμής. Η ομάδα δοκιμών εκτελεί τις δοκιμές που έχει σχεδιάσει με βάση τις απαιτήσεις και τον λεπτομερή σχεδιασμό.
Τυχόν προβλήματα θα διορθωθούν από την ομάδα ανάπτυξης. Μόλις ολοκληρωθεί η διαδικασία δοκιμής και επιδιόρθωσης, η εφαρμογή παραδίδεται στον τελικό χρήστη για δοκιμή αποδοχής. Ο τελικός χρήστης πραγματοποιεί έναν τελικό έλεγχο για να διαπιστώσει εάν η εφαρμογή συμμορφώνεται με τις αρχικές απαιτήσεις. Εάν εγκριθεί, εγκρίνει το τελικό προϊόν και το έργο ολοκληρώνεται.
Ο τελικός χρήστης πραγματοποιεί έναν τελικό έλεγχο για να διαπιστώσει εάν η εφαρμογή συμμορφώνεται με τις αρχικές απαιτήσεις. Εάν εγκριθεί, εγκρίνει το τελικό προϊόν και το έργο ολοκληρώνεται. Ο τελικός χρήστης πραγματοποιεί έναν τελικό έλεγχο για να διαπιστώσει εάν η εφαρμογή συμμορφώνεται με τις αρχικές απαιτήσεις. Εάν εγκριθεί, εγκρίνει το τελικό προϊόν και το έργο ολοκληρώνεται.
Ένα έργο μπορεί να έχει περισσότερες ή λιγότερες φάσεις όταν χρησιμοποιείται η προσέγγιση καταρράκτη, αλλά το βασικό χαρακτηριστικό είναι μια πολύ επίσημη έναρξη και τέλος κάθε φάσης, με πολύ επίσημα παραδοτέα.
Το πλεονέκτημα της προσέγγισης του καταρράκτη είναι ότι η ευθύνη της ομάδας που είναι υπεύθυνη για κάθε φάση είναι μεγαλύτερη. Είναι σαφές τι πρέπει να το παραδώσουν, πότε πρέπει να το παραδώσουν και σε ποιον πρέπει να το παραδώσουν. Συχνά, η ομάδα ανάπτυξης δεν χρειάζεται να αλληλεπιδράσει με τον χρήστη. Αυτό μπορεί να είναι πολύ χρήσιμο κατά την εξωτερική ανάθεση ανάπτυξης σε διαφορετική χώρα.
Το κύριο μειονέκτημα της προσέγγισης του καταρράκτη είναι ότι, σε ένα περιβάλλον όπου τα πάντα είναι οργανωμένα με πολύ επίσημο τρόπο, η ευελιξία να ανταποκρίνεται στις αλλαγές μειώνεται. Ακόμη και η μετακόμιση πρέπει να οργανωθεί. Πολύ λίγες εταιρείες φαίνεται να το κάνουν αυτό αποτελεσματικά, με αποτέλεσμα συχνά σημαντική αύξηση των γενικών εξόδων. Για τη διαχείριση του κόστους ενός έργου, ορισμένες εταιρείες καθυστερούν ακόμη και τυχόν αλλαγές στις απαιτήσεις μέχρι την αρχική παράδοση της εφαρμογής, παραδίδοντας ουσιαστικά μια εφαρμογή που δεν ανταποκρίνεται στις ανάγκες του τελικού χρήστη.
ευέλικτη ανάπτυξη
Πολλά μακροχρόνια έργα ανάπτυξης λογισμικού ξεπέρασαν τον προϋπολογισμό και δεν παρέδωσαν το προϊόν στην ώρα τους. Η αρχή της φιλοσοφίας ανάπτυξης ευέλικτου λογισμικού είναι η ελαχιστοποίηση του κινδύνου αναπτύσσοντας λογισμικό σε σύντομες χρονικές περιόδους, που ονομάζονται επαναλήψεις, οι οποίες συνήθως διαρκούν από μία έως τέσσερις εβδομάδες. Κάθε επανάληψη είναι σαν το δικό της μικροσκοπικό έργο λογισμικού και περιλαμβάνει όλες τις απαραίτητες εργασίες για την απελευθέρωση της αύξησης της νέας λειτουργικότητας: σχεδιασμός, ανάλυση απαιτήσεων, σχεδιασμός, κωδικοποίηση, δοκιμή και τεκμηρίωση. Ενώ μια επανάληψη μπορεί να μην προσθέτει αρκετή λειτουργικότητα για να εγγυηθεί την κυκλοφορία του προϊόντος, ένα ευέλικτο έργο λογισμικού στοχεύει να μπορεί να κυκλοφορήσει νέο λογισμικό στο τέλος κάθε επανάληψης. Στο τέλος κάθε επανάληψης, η ομάδα επαναξιολογεί τις προτεραιότητες του έργου.
Ο στόχος της ευέλικτης ανάπτυξης λογισμικού είναι να επιτευχθεί η ικανοποίηση των πελατών μέσω της ταχείας και συνεχούς παράδοσης χρήσιμου λογισμικού. με στόχο πάντα να χτίσει αυτό που χρειάζεται ο πελάτης. χαιρετίζω, αντί να αντιτάσσομαι, καθυστερημένες αλλαγές στις απαιτήσεις. προσαρμόζονται τακτικά στις μεταβαλλόμενες συνθήκες· να υπάρχει στενή και καθημερινή συνεργασία μεταξύ επιχειρηματιών και προγραμματιστών, στην οποία η πρόσωπο με πρόσωπο συνομιλία είναι η καλύτερη μορφή επικοινωνίας.
Το κύριο πλεονέκτημα της ευέλικτης ανάπτυξης λογισμικού είναι η ευελιξία στην αντιμετώπιση των αλλαγών, με στόχο πάντα την παράδοση σύμφωνα με τις επιχειρηματικές ανάγκες. Το μειονέκτημα, φυσικά, είναι η αύξηση της πολυπλοκότητας της διαχείρισης του πεδίου εφαρμογής, του σχεδιασμού και του προϋπολογισμού. Ένας άλλος κοινός κίνδυνος είναι η περιορισμένη προσοχή στην (τεχνική) τεκμηρίωση.
Σταδιακή Ανάπτυξη
Η σταδιακή ανάπτυξη λογισμικού είναι ένας συνδυασμός ευέλικτης ανάπτυξης και ανάπτυξης καταρράκτη. Μια εφαρμογή σχεδιάζεται, υλοποιείται και δοκιμάζεται σταδιακά έτσι ώστε κάθε προσαύξηση να μπορεί να παραδοθεί στον τελικό χρήστη. Το έργο δεν ολοκληρώνεται μέχρι να ολοκληρωθεί η τελευταία προσαύξηση. Στοχεύει στη συντόμευση του καταρράκτη ορίζοντας ενδιάμεσες αυξήσεις και χρησιμοποιώντας ορισμένα από τα πλεονεκτήματα της ευέλικτης ανάπτυξης. Με βάση τα σχόλια που ελήφθησαν για μια προηγούμενη αύξηση, μπορούν να γίνουν προσαρμογές κατά την παράδοση της επόμενης αύξησης. Η επόμενη προσαύξηση μπορεί να αποτελείται από νέο κώδικα, καθώς και τροποποιήσεις σε προηγουμένως παρεχόμενο κώδικα.
Το πλεονέκτημα είναι ότι οι διατυπώσεις παραμένουν σε ισχύ, αλλά η διαχείριση αλλαγών γίνεται ευκολότερη. Το κόστος δοκιμής και ανάπτυξης μιας εφαρμογής πολλές φορές θα είναι μεγαλύτερο από το να το κάνετε μόνο μία φορά.
Έλεγχος ροής προγράμματος
Η επιλογή μιας προσέγγισης για τον έλεγχο ροής προγράμματος είναι ένα πολύ αρχιτεκτονικό έργο. Ο στόχος είναι να δημιουργήσετε ένα προσχέδιο της εφαρμογής σας όπου, μόλις αρχίσετε να προσθέτετε λειτουργικότητα και κώδικα, όλα φαίνεται να έχουν τη δική τους θέση. Εάν έχετε αναθεωρήσει ή γράψει ποτέ κώδικα υψηλής ποιότητας, κατανοείτε αυτήν την αρχή.
Κωδικός Διοργανωτή
Το πρώτο βήμα στο σχεδιασμό της ροής του προγράμματος είναι η οργάνωση του κώδικα με τη θέσπιση ενός συνόλου κανόνων που θα βοηθήσουν στη δημιουργία ενός σχεδιαγράμματος ή περιγράμματος της εφαρμογής. Η συντήρηση, ο εντοπισμός σφαλμάτων και η διόρθωση σφαλμάτων θα είναι ευκολότερες επειδή ο κώδικας βρίσκεται σε μια λογική θέση. Αφού ολοκληρώσετε τη βάση, μπορείτε να επιλέξετε μια προσέγγιση για την εφαρμογή της λογικής της εφαρμογής σας.
Τα μοτίβα σχεδιασμού θα πρέπει να διαδραματίζουν σημαντικό ρόλο στο σχεδιασμό του ελέγχου ροής προγράμματος. Με τα χρόνια, έχει γραφτεί πολύς κώδικας και έχουν σχεδιαστεί πολλές λύσεις για επαναλαμβανόμενα προβλήματα. Αυτές οι λύσεις παρουσιάζονται σε σχέδια σχεδίασης. Η εφαρμογή ενός σχεδίου σχεδίου σε ένα κοινό πρόβλημα σχεδιασμού λογισμικού θα σας βοηθήσει να δημιουργήσετε λύσεις που είναι εύκολα αναγνωρίσιμες και μπορούν να εφαρμοστούν από τους συνομηλίκους σας. Τα μοναδικά προβλήματα θα εξακολουθούν να απαιτούν μοναδικές λύσεις, αλλά μπορείτε να χρησιμοποιήσετε σχέδια σχεδίασης για να σας καθοδηγήσουν στην επίλυσή τους.
Δημιουργία του Έργου
στρώματα
Το πρώτο βήμα είναι να εξετάσετε τα λογικά επίπεδα. Σημειώστε ότι τα επίπεδα δεν είναι ίδια με τα επίπεδα, συχνά συγχέονται ή θεωρούνται τα ίδια.
στρώσεις έναντι στρωμάτων
Τα επίπεδα έχουν να κάνουν με τη δημιουργία ορίων στον κώδικά σας. Το ανώτερο επίπεδο μπορεί να έχει αναφορές σε κώδικα στα επίπεδα παρακάτω, αλλά ένα επίπεδο δεν μπορεί ποτέ να έχει αναφορά σε κώδικα σε ένα επίπεδο παραπάνω. Τα επίπεδα αναφέρονται στη φυσική κατανομή των επιπέδων σε πολλούς υπολογιστές. Για παράδειγμα, σε μια εφαρμογή τριών επιπέδων, η διεπαφή χρήστη έχει σχεδιαστεί για να εκτελείται σε επιτραπέζιο υπολογιστή, η λογική της εφαρμογής έχει σχεδιαστεί για να εκτελείται σε διακομιστή εφαρμογών και η βάση δεδομένων εκτελείται σε διακομιστή βάσης δεδομένων, με αποκλειστικά δεδομένα και τον κώδικα σε κάθε Το στρώμα μπορεί να αποτελείται από πολλά στρώματα.
Εικόνα 8-1: Βασική οργάνωση τριών επιπέδων
Τα επίπεδα αναφέρονται σε επίπεδα αφαίρεσης. Τα επίπεδα που φαίνονται στο Σχήμα 8-1 ισχύουν για τις περισσότερες εφαρμογές. Αυτά τα επίπεδα αναφέρονται επίσης ως τα τρία κύρια επίπεδα και μπορεί να έχουν διάφορα άλλα ονόματα. Κατά κανόνα, ο κώδικας στο επίπεδο παρουσίασης μπορεί να καλεί υπηρεσίες στο επίπεδο λογικής εφαρμογής, αλλά το επίπεδο λογικής εφαρμογής δεν πρέπει να καλεί τη μέθοδο στο επίπεδο παρουσίασης. Το επίπεδο παρουσίασης δεν πρέπει ποτέ να καλεί απευθείας το επίπεδο πρόσβασης δεδομένων, καθώς αυτό θα παρακάμπτει τις ευθύνες που υλοποιούνται από το επίπεδο λογικής εφαρμογής. Το επίπεδο πρόσβασης δεδομένων δεν πρέπει ποτέ να καλεί το επίπεδο λογικής εφαρμογής.
Τα επίπεδα είναι απλώς μια αφαίρεση και πιθανώς ο ευκολότερος τρόπος για να υλοποιήσετε επίπεδα είναι να δημιουργήσετε φακέλους στο έργο σας και να προσθέσετε κώδικα στον κατάλληλο φάκελο. Μια πιο χρήσιμη προσέγγιση θα ήταν να τοποθετήσετε κάθε στρώμα σε ένα ξεχωριστό έργο, δημιουργώντας έτσι ξεχωριστές συναρμολογήσεις. Το πλεονέκτημα της τοποθέτησης της λογικής της εφαρμογής σας σε μια συγκρότηση βιβλιοθήκης είναι ότι θα σας επιτρέψει να δημιουργήσετε δοκιμές μονάδας, χρησιμοποιώντας το Microsoft Visual Studio ή το NUnit, για να ελέγξετε τη λογική. Δημιουργεί επίσης ευελιξία στην επιλογή πού θα αναπτυχθεί κάθε επίπεδο.
Φυσικά στρώματα
Σε μια εταιρική εφαρμογή, θα περιμένατε να έχετε πολλούς πελάτες για την ίδια λογική. Στην πραγματικότητα, αυτό που κάνει μια εφαρμογή εταιρική εφαρμογή είναι ότι θα αναπτυχθεί σε τρία επίπεδα: πελάτης, διακομιστής εφαρμογής και διακομιστής βάσης δεδομένων. Η εφαρμογή Microsoft Office Access που δημιουργήθηκε από το τμήμα πωλήσεων της εταιρείας σας, αν και είναι πολύ σημαντική για το τμήμα πωλήσεων, δεν είναι μια εταιρική εφαρμογή.
Σημειώστε ότι η λογική της εφαρμογής και τα επίπεδα πρόσβασης δεδομένων αναπτύσσονται συχνά μαζί στον διακομιστή εφαρμογών. Μέρος του σχεδιασμού του έργου είναι η επιλογή εάν θα έχετε πρόσβαση στον διακομιστή εφαρμογών χρησιμοποιώντας απομακρυσμένες υπηρεσίες .NET ή Web. Όποιο κι αν επιλέξετε, θα προσθέσετε κάποιο κώδικα για εύκολη πρόσβαση σε απομακρυσμένες υπηρεσίες στο επίπεδο παρουσίασης. Εάν χρησιμοποιείτε υπηρεσίες web για πρόσβαση σε υπηρεσίες στον διακομιστή εφαρμογών σας, το Visual Studio .NET θα κάνει τη δουλειά για εσάς και θα δημιουργήσει τον κωδικό διακομιστή μεσολάβησης, παρέχοντας αυτόματα μια υλοποίηση του μοτίβου απομακρυσμένου διακομιστή μεσολάβησης.
Προσθήκη μοτίβων σε επίπεδα
Τα τρία βασικά επίπεδα παρέχουν μια επισκόπηση υψηλού επιπέδου. Ας προσθέσουμε μερικά δομικά μοτίβα για να δημιουργήσουμε μια ισχυρή εταιρική αρχιτεκτονική. Το αποτέλεσμα φαίνεται στο Σχήμα 8-2.
Εστίαση στο επίπεδο λογικής εφαρμογής. Το σχήμα 8-2 δείχνει ότι η πρόσβαση στη λογική της εφαρμογής χρησιμοποιεί το μοτίβο πρόσοψης. Μια πρόσοψη είναι ένα αντικείμενο που παρέχει μια απλοποιημένη διεπαφή σε ένα μεγαλύτερο σώμα κώδικα, όπως μια βιβλιοθήκη κλάσης. Μια πρόσοψη μπορεί να μειώσει τις εξαρτήσεις εξωτερικού κώδικα από τις εσωτερικές λειτουργίες μιας βιβλιοθήκης, επειδή οι περισσότεροι κώδικας χρησιμοποιούν την πρόσοψη, επιτρέποντας έτσι μεγαλύτερη ευελιξία στην ανάπτυξη του συστήματος. Για να γίνει αυτό, η πρόσοψη θα παρέχει μια χονδρόκοκκη διεπαφή σε μια συλλογή από λεπτόκοκκα αντικείμενα.
ροή αποφάσεων
Ο έλεγχος ροής προγράμματος, γνωστός και ως ροή αποφάσεων, αφορά τον τρόπο σχεδίασης των υπηρεσιών στο επίπεδο λογικής εφαρμογής ή, όπως είδατε στην προηγούμενη παράγραφο, πώς σχεδιάζετε τις μεθόδους στην πρόσοψή σας.
Υπάρχουν δύο προσεγγίσεις για την οργάνωση των υπηρεσιών σας:
- προσανατολισμένος στη δράση
- καθοδηγούμενο από το κράτος
Προσέγγιση προσανατολισμένη στη δράση
Οργανώνοντας υπηρεσίες με βάση τις ενέργειες των χρηστών, εφαρμόζετε τη λογική της εφαρμογής προσφέροντας υπηρεσίες, καθεμία από τις οποίες χειρίζεται ένα συγκεκριμένο αίτημα από το επίπεδο παρουσίασης. Αυτό είναι επίσης γνωστό ως μοτίβο σεναρίου συναλλαγών. Αυτή η προσέγγιση είναι δημοφιλής επειδή είναι απλή και φαίνεται πολύ φυσική. Παραδείγματα μεθόδων που ακολουθούν αυτήν την προσέγγιση είναι το BookStoreService.AddNewOrder(παραγγελία) και το BookStoreService.CancelOrder(int orderId).
Η λογική που απαιτείται για την εκτέλεση της ενέργειας υλοποιείται πολύ διαδοχικά μέσα στη μέθοδο, καθιστώντας τον κώδικα πολύ ευανάγνωστο αλλά και δυσκολότερο στην επαναχρησιμοποίηση. Η χρήση πρόσθετων μοτίβων σχεδίασης, όπως το μοτίβο της μονάδας πίνακα, μπορεί να βοηθήσει στην αύξηση της επαναχρησιμοποίησης.
Προσέγγιση με γνώμονα το κράτος
Είναι επίσης δυνατό να εφαρμοστεί η ροή αποφάσεων της εφαρμογής με έναν πολύ πιο προσανατολισμένο στην κατάσταση τρόπο. Οι υπηρεσίες που προσφέρονται από τον διακομιστή εφαρμογών είναι πιο γενικής φύσης, για παράδειγμα BookStoreService.SaveOrder(Παραγγελία παραγγελίας). Αυτή η μέθοδος θα εξετάσει την κατάσταση της παραγγελίας και θα αποφασίσει εάν θα προσθέσετε μια νέα παραγγελία ή θα ακυρώσετε μια υπάρχουσα παραγγελία.
Έργα δομής δεδομένων
Πρέπει να κάνετε πολλές επιλογές κατά το σχεδιασμό των δομών δεδομένων σας. Η πρώτη επιλογή είναι ο μηχανισμός αποθήκευσης δεδομένων, η δεύτερη είναι η προβλεπόμενη χρήση των δεδομένων και η τρίτη είναι οι απαιτήσεις έκδοσης. Υπάρχουν τρεις τρόποι για να δείτε τα σχέδια δομών δεδομένων:
- Οι υπηρεσίες προσφέρουν δεδομένα. Τα δεδομένα είναι μια αντανάκλαση της σχεσιακής βάσης δεδομένων.
- Τα δεδομένα πρέπει να αντιστοιχίζονται σε αντικείμενα και οι υπηρεσίες παρέχουν πρόσβαση σε αντικείμενα.
- Τα δεδομένα που προσφέρονται από τις υπηρεσίες πρέπει να βασίζονται σε σχήματα.
Η επιλογή ενός από τα τρία ως βάση για τη δομή ροής δεδομένων σας θα πρέπει να γίνει σε πρώιμο στάδιο της διαδικασίας σχεδιασμού. Πολλές εταιρείες έχουν μια εταιρική κατευθυντήρια γραμμή που ορίζει μία από τις τρεις επιλογές για όλα τα έργα, αλλά όπου είναι δυνατόν, θα πρέπει να επαναξιολογήσετε τις επιλογές για κάθε έργο, επιλέγοντας τη βέλτιστη προσέγγιση για το συγκεκριμένο έργο.
Επιλογή μηχανής αποθήκευσης δεδομένων
Κατά το σχεδιασμό της εφαρμογής σας, αναμφίβολα θα πρέπει να σχεδιάσετε κάποιο είδος αποθήκευσης δεδομένων. Διατίθενται οι ακόλουθες αποθήκες και μορφές αποθήκευσης δεδομένων:
- Ρεκόρ
- αρχείο app.config
- xml αρχεία
- αρχεία απλού κειμένου
- Βάση δεδομένων
- ουρά μηνυμάτων
Κάθε κατάστημα έχει τα δικά του μοναδικά χαρακτηριστικά και μπορεί να προσαρμοστεί σε συγκεκριμένες απαιτήσεις.
Σχεδιασμός της ροής δεδομένων
Ροή δεδομένων με χρήση του ADO.NET
Εφαρμόζοντας υπηρεσίες με επίκεντρο τα δεδομένα στο επίπεδο λογικής εφαρμογής, θα σχεδιάσετε τη ροή δεδομένων σας χρησιμοποιώντας το ADO.NET. Η βιβλιοθήκη κλάσης .NET Framework παρέχει μια εκτενή διεπαφή προγραμματισμού εφαρμογών (API) για τον χειρισμό δεδομένων σε διαχειριζόμενο κώδικα. Αναφέρεται ως ADO.NET, το API μπορεί να βρεθεί στον χώρο ονομάτων System.Data. Ο πλήρης διαχωρισμός των φορέων δεδομένων και των αποθηκών δεδομένων είναι ένα σημαντικό χαρακτηριστικό σχεδιασμού του ADO.NET. Οι κλάσεις όπως το DataSet, το DataTable και το DataRow έχουν σχεδιαστεί για να αποθηκεύουν δεδομένα, αλλά δεν διατηρούν καμία γνώση από πού προέρχονται τα δεδομένα. Θεωρούνται αγνωστικιστές της πηγής δεδομένων. Ένα ξεχωριστό σύνολο κλάσεων, όπως οι SqlConnection, SqlDataAdapter και SqlCommand, φροντίζουν για τη σύνδεση σε μια πηγή δεδομένων, την ανάκτηση δεδομένων και τη συμπλήρωση του DataSet, του DataTable και του DataRow. Αυτές οι κλάσεις βρίσκονται σε υπο-χώρους ονομάτων όπως System.Data.Sql, System.Data.OleDB, System.Data.Oracle και ούτω καθεξής. Ανάλογα με την πηγή δεδομένων στην οποία θέλετε να συνδεθείτε, μπορείτε να χρησιμοποιήσετε κλάσεις στον σωστό χώρο ονομάτων και ανάλογα με το εύρος του προϊόντος που χρησιμοποιείτε, θα διαπιστώσετε ότι αυτές οι κλάσεις προσφέρουν περισσότερη ή λιγότερη λειτουργικότητα.
Εφόσον το DataSet δεν είναι συνδεδεμένο με την πηγή δεδομένων, μπορεί να χρησιμοποιηθεί με μεγάλη επιτυχία για τη διαχείριση της ροής δεδομένων σε μια εφαρμογή. Το Σχήμα 8-5 δείχνει τη ροή δεδομένων όταν το κάνετε αυτό.
Ας ρίξουμε μια ματιά σε αυτό το έργο και ας φανταστούμε ότι κάποιος έχει συνδεθεί στο βιβλιοπωλείο σας και έχει παραγγείλει τρία βιβλία. Το επίπεδο παρουσίασης διαχειριζόταν την κατάσταση του καλαθιού αγορών. Ο πελάτης είναι έτοιμος να κάνει την παραγγελία και έχει δώσει όλα τα απαραίτητα στοιχεία. Επιλέγει να στείλει παραγγελία. Η ιστοσελίδα μετατρέπει όλα τα δεδομένα σε ένα σύνολο δεδομένων που περιέχει δύο πίνακες δεδομένων, έναν για παραγγελία και έναν για παραγγελία. εισάγει ένα DataRow για την παραγγελία. και εισάγει τρεις γραμμές δεδομένων για τις γραμμές παραγγελίας. Στη συνέχεια, η ιστοσελίδα εμφανίζει αυτά τα δεδομένα ξανά στον χρήστη, δεσμεύοντας τα στοιχεία ελέγχου δεδομένων με το σύνολο δεδομένων και ρωτώντας Είστε σίγουροι; Ο χρήστης επιβεβαιώνει το αίτημα και υποβάλλεται στο λογικό επίπεδο της εφαρμογής. Το λογικό επίπεδο εφαρμογής ελέγχει το σύνολο δεδομένων για να δει εάν όλα τα απαιτούμενα πεδία έχουν μια τιμή και εκτελεί έναν έλεγχο για να δει εάν ο χρήστης έχει περισσότερα από 1000 US$. 00 σε ανεξόφλητους λογαριασμούς. Εάν όλα πάνε καλά, το σύνολο δεδομένων μεταβιβάζεται στο επίπεδο πρόσβασης δεδομένων, το οποίο συνδέεται με τη βάση δεδομένων και δημιουργεί δηλώσεις εισαγωγής από τις πληροφορίες του συνόλου δεδομένων.
Η χρήση του DataSet με αυτόν τον τρόπο είναι ένας γρήγορος και αποτελεσματικός τρόπος για τη δημιουργία μιας εφαρμογής και τη χρήση της ισχύος της Βιβλιοθήκης κλάσης Framework και της ικανότητας του ASP.NET να δεσμεύει δεδομένα σε διάφορα στοιχεία ελέγχου, όπως το GridView έναντι ενός συνόλου δεδομένων. Αντί να χρησιμοποιείτε απλά αντικείμενα DataSet, μπορείτε να χρησιμοποιήσετε αντικείμενα Typed DataSet και να βελτιώσετε την εμπειρία κωδικοποίησης εφαρμόζοντας κώδικα στο επίπεδο παρουσίασης καθώς και στο επίπεδο λογικής εφαρμογής. Το πλεονέκτημα αυτής της προσέγγισης είναι επίσης το μειονέκτημα της προσέγγισης. Μικρές αλλαγές στο μοντέλο δεδομένων δεν οδηγούν απαραίτητα σε πολλές μεθόδους που πρέπει να αλλάξουν τις υπογραφές τους. Έτσι, όσον αφορά τη συντήρηση, αυτό λειτουργεί πολύ καλά. Εάν θυμάστε ότι το επίπεδο παρουσίασης δεν είναι απαραίτητα μια διεπαφή χρήστη, μπορεί επίσης να είναι μια υπηρεσία ιστού. Και αν τροποποιήσετε τον ορισμό του συνόλου δεδομένων, ίσως επειδή μετονομάζετε ένα πεδίο στη βάση δεδομένων, τότε τροποποιείτε το συμβόλαιο στο οποίο έχει εγγραφεί η υπηρεσία Ιστού. Όπως μπορείτε να φανταστείτε, αυτό μπορεί να οδηγήσει σε ορισμένα σημαντικά προβλήματα. Αυτό το σενάριο λειτουργεί καλά εάν το επίπεδο παρουσίασης είναι απλώς μια διεπαφή χρήστη, αλλά για διεπαφές σε εξωτερικά συστήματα ή στοιχεία, θα θέλετε να αποκρύψετε τις εσωτερικές λειτουργίες της εφαρμογής σας και να μετατρέψετε τα δεδομένα σε κάτι διαφορετικό από έναν άμεσο κλώνο του μοντέλου δεδομένων σας και θα θέλετε να δημιουργήσετε αντικείμενα μεταφοράς δεδομένων (DTO).
Ροή δεδομένων με χρήση σχεσιακής χαρτογράφησης αντικειμένων
Η ροή δεδομένων που χρησιμοποιεί το ADO.NET είναι μια πολύ βασική στα δεδομένα προσέγγιση για τη διαχείριση της ροής δεδομένων. Τα δεδομένα και η λογική είναι διακριτά. Το άλλο άκρο του φάσματος ακολουθεί μια πιο αντικειμενοστρεφή προσέγγιση. Εδώ, δημιουργούνται κλάσεις για ομαδοποίηση δεδομένων και συμπεριφοράς. Ο στόχος είναι να οριστούν κλάσεις που μιμούνται τα δεδομένα και τη συμπεριφορά που βρίσκονται στον επιχειρηματικό τομέα για τον οποίο δημιουργήθηκε η εφαρμογή. Το αποτέλεσμα αναφέρεται συχνά ως επιχειρηματικό αντικείμενο. Η συλλογή των επιχειρηματικών αντικειμένων που απαρτίζουν την εφαρμογή ονομάζεται μοντέλο τομέα. Ορισμένοι προγραμματιστές ισχυρίζονται ότι ένα μοντέλο εμπλουτισμένου τομέα είναι καλύτερο για το σχεδιασμό πιο περίπλοκης λογικής. Είναι δύσκολο να αποδειχθεί ή να διαψευσθεί μια τέτοια δήλωση. Απλά να ξέρετε ότι έχετε μια επιλογή και είναι στο χέρι σας να την κάνετε.
Το Σχήμα 8-6 δείχνει μια ροή δεδομένων παρόμοια με την Εικόνα 8-5 , με τη διαφορά ότι τώρα έχετε προσθέσει το επίπεδο σχεσιακής αντιστοίχισης αντικειμένων και αντικαταστήσατε τα αντικείμενα DataSet με διαφορετικούς φορείς δεδομένων.
Τώρα κάντε το ίδιο βήμα προς βήμα όπως πριν. φανταστείτε ότι κάποιος συνδέθηκε με το βιβλιοπωλείο σας και παρήγγειλε τρία βιβλία. Το επίπεδο παρουσίασης διαχειριζόταν την κατάσταση του καλαθιού αγορών. Ο πελάτης είναι έτοιμος να κάνει την παραγγελία και έχει δώσει όλα τα απαραίτητα στοιχεία. Επιλέγει να στείλει παραγγελία. Η ιστοσελίδα μετατρέπει όλα τα δεδομένα σε DTO, κρατώντας δεδομένα για μία παραγγελία και με τρεις γραμμές παραγγελίας, δημιουργώντας τα αντικείμενα όπως απαιτείται. Η ιστοσελίδα εμφανίζει αυτά τα δεδομένα ξανά στον χρήστη, ελέγχει τη δέσμευση δεδομένων έναντι του DTO χρησιμοποιώντας το ObjectDataSource στο ASP.NET 2.0 και ρωτά Είσαι σίγουρος; Ο χρήστης επιβεβαιώνει την επιλογή και το DTO υποβάλλεται στο λογικό επίπεδο της εφαρμογής. Το επίπεδο λογικής εφαρμογής μετατρέπει το DTO σε επιχειρηματικό αντικείμενο τύπου Order με μια ιδιότητα να περιέχει τρία αντικείμενα OrderLine. Η μέθοδος παραγγελίας. Η Validate() καλείται να επικυρώσει την παραγγελία και να επαληθεύσει ότι όλα τα απαιτούμενα πεδία έχουν μια τιμή και γίνεται έλεγχος για να προσδιοριστεί εάν ο χρήστης έχει περισσότερα από R$ 1.000,00 σε εκκρεμή δελτία. Για να γίνει αυτό, η παραγγελία θα καλέσει Order.Customer.GetOutstandingBills(). Εάν όλα πάνε καλά, καλείται η μέθοδος Order.Save(). Το αίτημα θα περάσει μέσα από το επίπεδο σχεσιακής αντιστοίχισης αντικειμένων, όπου το αίτημα και οι σειρές του αιτήματος αντιστοιχίζονται σε έναν πίνακα δεδομένων σε ένα σύνολο δεδομένων και το σύνολο δεδομένων μεταβιβάζεται στο επίπεδο πρόσβασης δεδομένων, το οποίο συνδέεται με τη βάση δεδομένων και δημιουργεί δηλώσεις εισαγωγής από τις πληροφορίες στο σύνολο δεδομένων. Υπάρχουν, φυσικά, πολλοί τρόποι με τους οποίους μπορεί να πραγματοποιηθεί αντικειμενική σχεσιακή αντιστοίχιση, αλλά δεν θα περιλαμβάνουν όλοι τη μετατροπή σε ένα σύνολο δεδομένων. Ορισμένοι θα δημιουργήσουν απευθείας την εντολή εισαγωγής, αλλά εξακολουθούν να χρησιμοποιούν το επίπεδο πρόσβασης δεδομένων για να εκτελέσουν αυτήν τη δήλωση.
Όπως μπορείτε να δείτε, γίνονται κάποιες μεταμορφώσεις. Η χρήση DTO είναι απαραίτητη επειδή ένα επιχειρηματικό αντικείμενο υλοποιεί τη συμπεριφορά και η συμπεριφορά υπόκειται σε αλλαγές. Για να ελαχιστοποιήσετε τον αντίκτυπο αυτών των αλλαγών στο επίπεδο παρουσίασης, πρέπει να μετατρέψετε τα δεδομένα από το επιχειρηματικό αντικείμενο και σε αντικείμενο μεταφοράς δεδομένων. Στην Java, το αντικείμενο μεταφοράς δεδομένων αναφέρεται συχνά ως αντικείμενο τιμής.
Ένα μεγάλο πλεονέκτημα της εργασίας με επιχειρηματικά αντικείμενα είναι ότι βοηθά πραγματικά στην οργάνωση του κώδικά σας. Αν κοιτάξετε πίσω σε ένα κομμάτι περίπλοκης λογικής, είναι συνήθως πολύ ευανάγνωστο επειδή υπάρχει πολύ λίγος κώδικας υδραυλικών εγκαταστάσεων. Το μειονέκτημα είναι ότι τα περισσότερα καταστήματα δεδομένων εξακολουθούν να είναι σχεσιακά και η αντιστοίχιση επιχειρηματικών αντικειμένων σε σχεσιακά δεδομένα μπορεί να γίνει αρκετά περίπλοκη.
υπηρεσίες που βασίζονται σε σχήματα
Μόλις είδατε δύο αντίθετα όσον αφορά τη διαχείριση της ροής δεδομένων. Πολλές παραλλαγές είναι δυνατές. Μια κοινή είναι η παραλλαγή στην οποία ένα σύνολο δεδομένων χρησιμοποιείται ως ο βασικός φορέας δεδομένων της διεπαφής χρήστη για την αποθήκευση δεδομένων, αλλά χωριστά σχήματα (DTO) χρησιμοποιούνται για υπηρεσίες Ιστού που καλούνται από άλλα συστήματα. Το επίπεδο εφαρμογής μετατρέπει τα σχεσιακά δεδομένα σε ένα προκαθορισμένο σχήμα. Το κύριο πλεονέκτημα αυτού είναι ότι οποιαδήποτε εφαρμογή που αναφέρεται στην υπηρεσία δεν εξαρτάται από κανένα είδος εσωτερικής υλοποίησης του στοιχείου. Αυτό επιτρέπει μεγαλύτερη ευελιξία στην έκδοση εκδόσεων, συμβατότητα προς τα πίσω των διεπαφών και τη δυνατότητα αλλαγής της υλοποίησης του στοιχείου χωρίς αλλαγή της διεπαφής της υπηρεσίας.
Φυσικά, μπορείτε να χρησιμοποιήσετε επιχειρηματικά αντικείμενα στην εφαρμογή Ιστού και να παρακάμψετε τον μετασχηματισμό DTO, αλλά αυτό συνήθως λειτουργεί καλά μόνο εάν η λογική της εφαρμογής υλοποιείται μαζί με την εφαρμογή Ιστού. Να θυμάστε ότι για να καλέσετε την Order.Save() θα χρειαστείτε μια σύνδεση βάσης δεδομένων. Το αν αυτό είναι επιθυμητό εξαρτάται από εσάς και πιθανώς τον διευθυντή ασφαλείας σας.