Η άνοιξη είναι αναμφισβήτητα ένα από τα πιο δημοφιλή πλαίσια Java, και επίσης ένα ισχυρό θηρίο για να εξημερώσει. Ενώ οι βασικές του έννοιες είναι αρκετά εύκολο να κατανοηθούν, το να γίνετε ένας ισχυρός προγραμματιστής Spring απαιτεί λίγο χρόνο και προσπάθεια.
Σε αυτό το άρθρο θα καλύψουμε μερικά από τα πιο συνηθισμένα λάθη την άνοιξη, ειδικά προσανατολισμένα στις εφαρμογές ιστού και το Spring Boot. Οπως και Ο ιστότοπος της Spring Boot δηλώνει, το Spring Boot παίρνει ένα απόψεις σχετικά με τον τρόπο κατασκευής εφαρμογών έτοιμων για παραγωγή, οπότε αυτό το άρθρο θα προσπαθήσει να μιμηθεί αυτήν την προβολή και να παρέχει μια επισκόπηση ορισμένων συμβουλών που θα ενσωματωθούν καλά στην τυπική ανάπτυξη εφαρμογών ιστού Spring Boot.
Σε περίπτωση που δεν είστε πολύ εξοικειωμένοι με το Spring Boot, αλλά θα θέλατε να δοκιμάσετε μερικά από τα πράγματα που αναφέρονται, έχω δημιουργήσει ένα αποθετήριο GitHub που συνοδεύει αυτό το άρθρο . Εάν αισθάνεστε χαμένοι σε οποιοδήποτε σημείο κατά τη διάρκεια του άρθρου, σας συνιστούμε να κλωνοποιήσετε το αποθετήριο και να παίξετε με τον κωδικό στον τοπικό υπολογιστή σας.
Το επιτυγχάνουμε με αυτό το κοινό λάθος επειδή το « δεν εφευρέθηκε εδώ Το σύνδρομο είναι αρκετά κοινό στον κόσμο ανάπτυξης λογισμικού. Τα συμπτώματα που περιλαμβάνουν την τακτική επανεγγραφή κομματιών κώδικα που χρησιμοποιούνται συχνά και πολλοί προγραμματιστές φαίνεται να υποφέρουν από αυτόν.
Ενώ η κατανόηση των εσωτερικών μιας συγκεκριμένης βιβλιοθήκης και η εφαρμογή της είναι ως επί το πλείστον καλή και απαραίτητη (και μπορεί να είναι μια εξαιρετική διαδικασία μάθησης), είναι επιζήμιο για την ανάπτυξή σας ως μηχανικός λογισμικού να αντιμετωπίζετε συνεχώς την ίδια εφαρμογή χαμηλού επιπέδου Λεπτομέριες. Υπάρχει ένας λόγος για τον οποίο υπάρχουν αφαιρέσεις και πλαίσια όπως το Spring, το οποίο είναι ακριβώς για να σας χωρίσει από την επαναλαμβανόμενη χειροκίνητη εργασία και να σας επιτρέψει να επικεντρωθείτε σε λεπτομέρειες υψηλότερου επιπέδου - αντικείμενα τομέα και επιχειρηματική λογική.
Αγκαλιάστε λοιπόν τις αφαιρέσεις - την επόμενη φορά που θα αντιμετωπίσετε ένα συγκεκριμένο πρόβλημα, κάντε μια γρήγορη αναζήτηση πρώτα και καθορίστε εάν μια βιβλιοθήκη που λύνει αυτό το πρόβλημα έχει ήδη ενσωματωθεί στην Άνοιξη. Σήμερα, είναι πιθανό να βρείτε μια κατάλληλη υπάρχουσα λύση. Ως παράδειγμα μιας χρήσιμης βιβλιοθήκης, θα χρησιμοποιώ Έργο Lombok σχολιασμοί σε παραδείγματα για το υπόλοιπο αυτού του άρθρου. Το Lombok χρησιμοποιείται ως γεννήτρια κώδικα boilerplate και ο τεμπέλης προγραμματιστής μέσα σας ελπίζουμε ότι δεν θα πρέπει να έχετε πρόβλημα να εξοικειωθείτε με τη βιβλιοθήκη. Για παράδειγμα, δείτε τι ' τυπικό φασόλι Java Μοιάζει με τον Λομπόκ:
@Getter @Setter @NoArgsConstructor public class Bean implements Serializable { int firstBeanProperty; String secondBeanProperty; } Όπως μπορείτε να φανταστείτε, ο παραπάνω κώδικας συγκεντρώνει:
public class Bean implements Serializable { private int firstBeanProperty; private String secondBeanProperty; public int getFirstBeanProperty() { return this.firstBeanProperty; } public String getSecondBeanProperty() { return this.secondBeanProperty; } public void setFirstBeanProperty(int firstBeanProperty) { this.firstBeanProperty = firstBeanProperty; } public void setSecondBeanProperty(String secondBeanProperty) { this.secondBeanProperty = secondBeanProperty; } public Bean() { } } Σημειώστε, ωστόσο, ότι πιθανότατα θα πρέπει να εγκαταστήσετε μια προσθήκη σε περίπτωση που σκοπεύετε να χρησιμοποιήσετε το Lombok με το IDE σας. Μπορείτε να βρείτε την έκδοση του plugin του IntelliJ IDEA εδώ .
Η έκθεση της εσωτερικής σας δομής δεν είναι ποτέ καλή ιδέα, διότι δημιουργεί δυσκαμψία στο σχεδιασμό υπηρεσιών και, κατά συνέπεια, προωθεί κακές πρακτικές κωδικοποίησης. Τα εσωτερικά 'διαρροής' εκδηλώνονται καθιστώντας τη δομή της βάσης δεδομένων προσβάσιμη από ορισμένα τελικά σημεία API. Για παράδειγμα, ας υποθέσουμε ότι το ακόλουθο POJO ('Plain Old Java Object') αντιπροσωπεύει έναν πίνακα στη βάση δεδομένων σας:
@Entity @NoArgsConstructor @Getter public class TopTalentEntity { @Id @GeneratedValue private Integer id; @Column private String name; public TopTalentEntity(String name) { this.name = name; } } Ας υποθέσουμε ότι υπάρχει ένα τελικό σημείο που πρέπει να έχει πρόσβαση στο TopTalentEntity δεδομένα. Δελεάζοντας όπως είναι να επιστρέψετε TopTalentEntity περιπτώσεις, μια πιο ευέλικτη λύση θα ήταν η δημιουργία μιας νέας κλάσης που θα αντιπροσωπεύει το TopTalentEntity δεδομένα στο τελικό σημείο του API:
@AllArgsConstructor @NoArgsConstructor @Getter public class TopTalentData { private String name; } Με αυτόν τον τρόπο, η πραγματοποίηση αλλαγών στο back-end της βάσης δεδομένων σας δεν θα απαιτήσει επιπλέον αλλαγές στο επίπεδο υπηρεσίας. Σκεφτείτε τι θα συνέβαινε στην περίπτωση προσθήκης πεδίου «κωδικού πρόσβασης» στο TopTalentEntity για την αποθήκευση των κωδικών κατακερματισμού των χρηστών σας στη βάση δεδομένων - χωρίς μια εφαρμογή σύνδεσης όπως TopTalentData, ξεχνώντας να αλλάξετε το front-end της υπηρεσίας θα εκθέσει κατά λάθος μερικές πολύ ανεπιθύμητες μυστικές πληροφορίες!
Καθώς η εφαρμογή σας μεγαλώνει, η οργάνωση κώδικα αρχίζει να γίνεται όλο και πιο σημαντικό θέμα. Κατά ειρωνικό τρόπο, οι περισσότερες από τις καλές αρχές της μηχανικής λογισμικού αρχίζουν να καταρρέουν σε κλίμακα - ειδικά σε περιπτώσεις όπου δεν έχει δοθεί ιδιαίτερη προσοχή στο σχεδιασμό αρχιτεκτονικής εφαρμογών. Ένα από τα πιο συνηθισμένα λάθη που οι προγραμματιστές τείνουν τότε να υποκύψουν είναι η ανάμειξη ανησυχιών κώδικα και είναι εξαιρετικά εύκολο να το κάνετε!
Αυτό που συνήθως σπάει διαχωρισμός των ανησυχιών είναι απλώς «απόρριψη» νέας λειτουργικότητας σε υπάρχουσες τάξεις. Φυσικά, αυτή είναι μια εξαιρετική βραχυπρόθεσμη λύση (για αρχάριους, απαιτεί λιγότερη πληκτρολόγηση), αλλά αναπόφευκτα γίνεται ένα πρόβλημα πιο πέρα από το δρόμο, είτε κατά τη διάρκεια δοκιμών, συντήρησης ή κάπου ενδιάμεσα. Εξετάστε τον ακόλουθο ελεγκτή, ο οποίος επιστρέφει TopTalentData από το αποθετήριο του:
@RestController public class TopTalentController { private final TopTalentRepository topTalentRepository; @RequestMapping('/toptal/get') public List getTopTalent() { return topTalentRepository.findAll() .stream() .map(this::entityToData) .collect(Collectors.toList()); } private TopTalentData entityToData(TopTalentEntity topTalentEntity) { return new TopTalentData(topTalentEntity.getName()); } } Αρχικά, δεν φαίνεται να υπάρχει κάτι ιδιαίτερα λάθος με αυτό το κομμάτι κώδικα. παρέχει μια λίστα TopTalentData που ανακτάται από TopTalentEntity περιπτώσεις. Αν ρίξουμε μια πιο προσεκτική ματιά, μπορούμε να δούμε ότι υπάρχουν πραγματικά μερικά πράγματα που TopTalentController παίζει εδώ? δηλαδή αντιστοιχίζει αιτήματα σε ένα συγκεκριμένο τελικό σημείο, ανακτά δεδομένα από ένα αποθετήριο και μετατρέπει οντότητες που λαμβάνονται από TopTalentRepository σε διαφορετική μορφή. Μια «καθαρότερη» λύση θα μπορούσε να χωρίσει αυτές τις ανησυχίες στις δικές τους τάξεις. Μπορεί να μοιάζει κάπως έτσι:
@RestController @RequestMapping('/toptal') @AllArgsConstructor public class TopTalentController { private final TopTalentService topTalentService; @RequestMapping('/get') public List getTopTalent() { return topTalentService.getTopTalent(); } } @AllArgsConstructor @Service public class TopTalentService { private final TopTalentRepository topTalentRepository; private final TopTalentEntityConverter topTalentEntityConverter; public List getTopTalent() { return topTalentRepository.findAll() .stream() .map(topTalentEntityConverter::toResponse) .collect(Collectors.toList()); } } @Component public class TopTalentEntityConverter { public TopTalentData toResponse(TopTalentEntity topTalentEntity) { return new TopTalentData(topTalentEntity.getName()); } } Ένα επιπλέον πλεονέκτημα αυτής της ιεραρχίας είναι ότι μας επιτρέπει να προσδιορίσουμε πού βρίσκεται η λειτουργικότητα, ελέγχοντας μόνο το όνομα της τάξης. Επιπλέον, κατά τη διάρκεια των δοκιμών μπορούμε εύκολα να αντικαταστήσουμε οποιαδήποτε από τις τάξεις με μια ψεύτικη εφαρμογή, εάν προκύψει ανάγκη.
Το θέμα της συνέπειας δεν είναι απαραιτήτως αποκλειστικό για το Spring (ή Java, για αυτό το θέμα), αλλά εξακολουθεί να είναι μια σημαντική πτυχή που πρέπει να ληφθεί υπόψη όταν εργάζεστε σε έργα Spring. Ενώ το στυλ κωδικοποίησης μπορεί να είναι κατάλληλο για συζήτηση (και είναι συνήθως θέμα συμφωνίας εντός μιας ομάδας ή σε μια ολόκληρη εταιρεία), το να έχεις ένα κοινό πρότυπο αποδεικνύεται ότι είναι μια μεγάλη παραγωγικότητα. Αυτό ισχύει ιδιαίτερα για τις ομάδες πολλών ατόμων. Η συνέπεια επιτρέπει τη μεταβίβαση χωρίς να δαπανώνται πολλοί πόροι στο χέρι ή να παρέχονται μακροχρόνιες εξηγήσεις σχετικά με τις ευθύνες διαφορετικών τάξεων
Σκεφτείτε ένα έργο Spring με διάφορα αρχεία διαμόρφωσης, υπηρεσίες και ελεγκτές. Όντας σημασιολογικά συνεπής στην ονομασία τους, δημιουργείται μια εύχρηστη δομή όπου κάθε νέος προγραμματιστής μπορεί να διαχειρίζεται τον κώδικα. προσθήκη επιθημάτων Config στις τάξεις διαμόρφωσής σας, επιθήματα υπηρεσιών στις υπηρεσίες σας και επιθήματα ελεγκτή στους ελεγκτές σας, για παράδειγμα.
Σχετικά στενά με το θέμα της συνέπειας, ο χειρισμός σφαλμάτων από την πλευρά του διακομιστή αξίζει ιδιαίτερη έμφαση. Εάν χρειάστηκε ποτέ να χειριστείτε τις απαντήσεις εξαιρέσεων από ένα κακώς γραμμένο API, ίσως γνωρίζετε γιατί - μπορεί να είναι πόνος να αναλύσετε σωστά τις εξαιρέσεις και ακόμη πιο οδυνηρό να προσδιορίσετε τον λόγο για τον οποίο αυτές οι εξαιρέσεις εμφανίστηκαν αρχικά.
Ως προγραμματιστής API, θα θέλατε ιδανικά να καλύψετε όλα τα τελικά σημεία που αντιμετωπίζουν οι χρήστες και να τα μεταφράσετε σε μια κοινή μορφή σφάλματος. Αυτό συνήθως σημαίνει ότι έχετε έναν γενικό κωδικό σφάλματος και περιγραφή αντί για τη λύση αντιγραφής α) επιστρέφοντας ένα μήνυμα 'Σφάλμα εσωτερικού διακομιστή 500' ή β) απλώς ρίχνοντας το ίχνος στοίβας στον χρήστη (το οποίο θα έπρεπε πραγματικά να αποφευχθεί με κάθε κόστος αφού εκθέτει τα εσωτερικά σας εκτός από το ότι είναι δύσκολο να χειριστείτε την πλευρά του πελάτη).
Ένα παράδειγμα μιας κοινής μορφής απόκρισης σφάλματος μπορεί να είναι:
@Value public class ErrorResponse { private Integer errorCode; private String errorMessage; } Κάτι παρόμοιο με αυτό συναντάται συνήθως στα πιο δημοφιλή API και τείνει να λειτουργεί καλά καθώς μπορεί να τεκμηριωθεί εύκολα και συστηματικά. Η μετάφραση εξαιρέσεων σε αυτήν τη μορφή μπορεί να γίνει παρέχοντας το @ExceptionHandler σχολιασμός σε μια μέθοδο (ένα παράδειγμα σχολιασμού είναι στο Κοινό λάθος # 6).
Ανεξάρτητα από το αν συναντάται σε επιτραπέζιους υπολογιστές ή εφαρμογές ιστού, Spring ή no Spring, το multithreading μπορεί να είναι ένα δύσκολο παξιμάδι. Τα προβλήματα που προκαλούνται από την παράλληλη εκτέλεση προγραμμάτων είναι νευρικώς δυσνόητα και συχνά πολύ δύσκολο να εντοπιστούν - στην πραγματικότητα, λόγω της φύσης του προβλήματος, μόλις συνειδητοποιήσετε ότι αντιμετωπίζετε ένα ζήτημα παράλληλης εκτέλεσης που πιθανότατα θα πάτε πρέπει να εγκαταλείψετε εντελώς το πρόγραμμα εντοπισμού σφαλμάτων και να ελέγξετε τον κωδικό σας 'με το χέρι' μέχρι να βρείτε την αιτία του ριζικού σφάλματος. Δυστυχώς, δεν υπάρχει λύση κοπής cookie για την επίλυση τέτοιων ζητημάτων. ανάλογα με τη συγκεκριμένη περίπτωσή σας, θα πρέπει να αξιολογήσετε την κατάσταση και στη συνέχεια να επιτεθείτε στο πρόβλημα από τη γωνία που θεωρείτε ότι είναι καλύτερη.
Στην ιδανική περίπτωση, φυσικά, θα θέλατε να αποφύγετε τα σφάλματα πολλαπλών νημάτων. Και πάλι, μια προσέγγιση για όλα τα μεγέθη δεν υπάρχει για να γίνει αυτό, αλλά εδώ είναι μερικές πρακτικές σκέψεις για τον εντοπισμό σφαλμάτων και την πρόληψη σφαλμάτων πολλαπλών νημάτων:
Πρώτα, να θυμάστε πάντα το ζήτημα του «παγκόσμιου κράτους». Εάν δημιουργείτε μια εφαρμογή πολλαπλών νημάτων, απολύτως οτιδήποτε μπορεί να τροποποιηθεί παγκοσμίως θα πρέπει να παρακολουθείται στενά και, εάν είναι δυνατόν, να αφαιρείται εντελώς. Εάν υπάρχει λόγος για τον οποίο η παγκόσμια μεταβλητή πρέπει να παραμείνει τροποποιήσιμη, χρησιμοποιήστε προσεκτικά συγχρονισμός και παρακολουθήστε την απόδοση της εφαρμογής σας για να επιβεβαιώσετε ότι δεν είναι αργή λόγω των πρόσφατων περιόδων αναμονής.
Αυτό προέρχεται κατευθείαν από λειτουργικός προγραμματισμός Και, προσαρμοσμένο στο OOP, δηλώνει ότι πρέπει να αποφεύγεται η μεταβλητότητα της τάξης και η αλλαγή της κατάστασης. Αυτό, εν συντομία, σημαίνει ότι παραιτείται από τις μεθόδους ρύθμισης και έχει ιδιωτικά τελικά πεδία σε όλες τις κατηγορίες μοντέλων σας. Η μόνη φορά που οι τιμές τους μεταλλάσσονται είναι κατά τη διάρκεια της κατασκευής. Με αυτόν τον τρόπο μπορείτε να είστε σίγουροι ότι δεν προκύπτουν προβλήματα διαφωνίας και ότι η πρόσβαση σε ιδιότητες αντικειμένου θα παρέχει τις σωστές τιμές ανά πάσα στιγμή.
Αξιολογήστε πού μπορεί να προκαλέσει προβλήματα η εφαρμογή σας και καταγράψτε προληπτικά όλα τα κρίσιμα δεδομένα. Εάν παρουσιαστεί σφάλμα, θα είστε ευγνώμονες που έχετε πληροφορίες που δηλώνουν ποια αιτήματα ελήφθησαν και έχετε καλύτερη εικόνα για το γιατί η εφαρμογή σας συμπεριέλαβε. Είναι και πάλι απαραίτητο να σημειωθεί ότι η καταγραφή εισάγει πρόσθετο αρχείο I / O και επομένως δεν πρέπει να γίνεται κατάχρηση, καθώς μπορεί να επηρεάσει σοβαρά την απόδοση της εφαρμογής σας.
Κάθε φορά που χρειάζεστε αναπαραγωγή των δικών σας νημάτων (π.χ. για την υποβολή αιτημάτων ασύγχυσης σε διαφορετικές υπηρεσίες), χρησιμοποιήστε ξανά τις υπάρχουσες ασφαλείς εφαρμογές αντί να δημιουργήσετε τις δικές σας λύσεις. Αυτό, ως επί το πλείστον, σημαίνει χρήση Υπηρεσίες και το τακτοποιημένο λειτουργικό στιλ της Java 8 Ολοκληρώθηκε το μέλλον για δημιουργία νήματος. Η άνοιξη επιτρέπει επίσης την ασύγχρονη επεξεργασία αιτημάτων μέσω του Αποτέλεσμα τάξη.
Ας υποθέσουμε ότι η υπηρεσία TopTalent από νωρίτερα απαιτεί ένα τελικό σημείο για την προσθήκη νέων Top Talents. Επιπλέον, ας πούμε ότι, για κάποιο πραγματικά έγκυρο λόγο, κάθε νέο όνομα πρέπει να έχει μήκος 10 χαρακτήρων. Ένας τρόπος για να το κάνετε αυτό μπορεί να είναι ο εξής:
@RequestMapping('/put') public void addTopTalent(@RequestBody TopTalentData topTalentData) { boolean nameNonExistentOrHasInvalidLength = Optional.ofNullable(topTalentData) .map(TopTalentData::getName) .map(name -> name.length() == 10) .orElse(true); if (nameNonExistentOrInvalidLength) { // throw some exception } topTalentService.addTopTalent(topTalentData); } Ωστόσο, τα παραπάνω (εκτός από την κακή κατασκευή) δεν είναι πραγματικά μια «καθαρή» λύση. Ελέγχουμε για περισσότερους από έναν τύπους ισχύος (δηλαδή, ότι TopTalentData δεν είναι μηδενικό, και ότι TopTalentData.name δεν είναι μηδενικό, και ότι TopTalentData.name έχει μήκος 10 χαρακτήρων), καθώς και εξαίρεση εάν τα δεδομένα δεν είναι έγκυρα.
Αυτό μπορεί να εκτελεστεί πολύ πιο καθαρά χρησιμοποιώντας Επικυρωτής αδρανοποίησης με την Άνοιξη. Ας κάνουμε τον πρώτο αντιδραστήρα το addTopTalent μέθοδος για την υποστήριξη επικύρωσης:
@RequestMapping('/put') public void addTopTalent(@Valid @NotNull @RequestBody TopTalentData topTalentData) { topTalentService.addTopTalent(topTalentData); } @ExceptionHandler @ResponseStatus(HttpStatus.BAD_REQUEST) public ErrorResponse handleInvalidTopTalentDataException(MethodArgumentNotValidException methodArgumentNotValidException) { // handle validation exception } Επιπλέον, θα πρέπει να υποδείξουμε ποια ιδιότητα θέλουμε να επικυρώσουμε στο TopTalentData τάξη:
public class TopTalentData { @Length(min = 10, max = 10) @NotNull private String name; } Τώρα το Spring θα αναχαιτίσει το αίτημα και θα το επικυρώσει πριν από την επίκληση της μεθόδου - δεν χρειάζεται να χρησιμοποιήσετε επιπλέον μη αυτόματες δοκιμές.
Ένας άλλος τρόπος που θα μπορούσαμε να επιτύχουμε το ίδιο πράγμα είναι να δημιουργήσουμε τους δικούς μας σχολιασμούς. Αν και συνήθως θα χρησιμοποιείτε προσαρμοσμένους σχολιασμούς μόνο όταν οι ανάγκες σας υπερβαίνουν Το ενσωματωμένο σύνολο περιορισμών του Hibernate , για αυτό το παράδειγμα ας προσποιηθούμε ότι το @Length δεν υπάρχει. Θα κάνατε έναν επικυρωτή που θα ελέγχει το μήκος της συμβολοσειράς δημιουργώντας δύο επιπλέον τάξεις, μία για επικύρωση και μία για ιδιότητες σχολιασμού:
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER}) @Retention(RetentionPolicy.RUNTIME) @Documented @Constraint(validatedBy = { MyAnnotationValidator.class }) public @interface MyAnnotation { String message() default 'String length does not match expected'; Class[] groups() default {}; Class[] payload() default {}; int value(); } @Component public class MyAnnotationValidator implements ConstraintValidator { private int expectedLength; @Override public void initialize(MyAnnotation myAnnotation) { this.expectedLength = myAnnotation.value(); } @Override public boolean isValid(String s, ConstraintValidatorContext constraintValidatorContext) } Λάβετε υπόψη ότι σε αυτές τις περιπτώσεις, οι βέλτιστες πρακτικές για τον διαχωρισμό των ανησυχιών απαιτούν από εσάς να επισημάνετε μια ιδιότητα ως έγκυρη εάν είναι μηδενική (s == null στη μέθοδο isValid) και, στη συνέχεια, να χρησιμοποιήσετε μια @NotNull σχολιασμός εάν αυτή είναι μια πρόσθετη απαίτηση για την ιδιοκτησία:
public class TopTalentData { @MyAnnotation(value = 10) @NotNull private String name; } Ενώ η XML ήταν αναγκαιότητα για προηγούμενες εκδόσεις της Άνοιξης, σήμερα το μεγαλύτερο μέρος της διαμόρφωσης μπορεί να γίνει αποκλειστικά μέσω κώδικα Java / σχολιασμών. Οι διαμορφώσεις XML θέτουν απλώς ως πρόσθετο και περιττό κώδικα boilerplate.
Αυτό το άρθρο (καθώς και το συνοδευτικό αποθετήριο του GitHub) χρησιμοποιεί σχολιασμούς για τη διαμόρφωση της Άνοιξης και της Άνοιξης γνωρίζει ποια φασόλια πρέπει να συνδέσει επειδή το ριζικό πακέτο έχει σχολιαστεί με @SpringBootApplication σύνθετος σχολιασμός, όπως:
@SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } Ο σύνθετος σχολιασμός (μπορείτε να μάθετε περισσότερα σχετικά με αυτό στο Άνοιξη τεκμηρίωσης απλώς δίνει στο Spring μια υπόδειξη για το ότι τα πακέτα πρέπει να σαρωθούν για να ανακτήσουν τα φασόλια. Στην συγκεκριμένη περίπτωση, αυτό σημαίνει ότι τα ακόλουθα κάτω από το πακέτο (co.kukurin) θα χρησιμοποιηθούν για καλωδίωση:
@Component (TopTalentConverter, MyAnnotationValidator)@RestController (TopTalentController)@Repository (TopTalentRepository)@Service (TopTalentService) τάξειςΕάν είχαμε επιπλέον @Configuration σχολιασμένες τάξεις θα ελέγχονταν επίσης για διαμόρφωση με βάση το Java.
Ένα πρόβλημα που συναντάται συχνά στην ανάπτυξη διακομιστή είναι η διάκριση μεταξύ διαφορετικών τύπων διαμόρφωσης, συνήθως των παραμέτρων παραγωγής και ανάπτυξης. Αντί να αντικαθιστάτε με μη αυτόματο τρόπο διάφορες καταχωρήσεις διαμόρφωσης κάθε φορά που αλλάζετε από δοκιμές στην ανάπτυξη της εφαρμογής σας, ένας πιο αποτελεσματικός τρόπος θα ήταν να χρησιμοποιήσετε προφίλ.
Εξετάστε την περίπτωση όπου χρησιμοποιείτε μια βάση δεδομένων στη μνήμη για τοπική ανάπτυξη, με μια βάση δεδομένων MySQL στην παραγωγή. Αυτό, στην ουσία, θα σήμαινε ότι θα χρησιμοποιείτε διαφορετική διεύθυνση URL και (ελπίζουμε) διαφορετικά διαπιστευτήρια για πρόσβαση σε καθένα από τα δύο. Ας δούμε πώς θα μπορούσε να γίνει αυτό δύο διαφορετικά αρχεία διαμόρφωσης:
# set default profile to 'dev' spring.profiles.active: dev # production database details spring.datasource.url: 'jdbc:mysql://localhost:3306/toptal' spring.datasource.username: root spring.datasource.password: spring.datasource.url: 'jdbc:h2:mem:' spring.datasource.platform: h2 Προφανώς δεν θα θέλατε να εκτελέσετε κατά λάθος οποιεσδήποτε ενέργειες στη βάση δεδομένων παραγωγής σας ενώ παίζετε με τον κωδικό, επομένως είναι λογικό να ορίσετε το προεπιλεγμένο προφίλ σε dev. Στον διακομιστή, μπορείτε στη συνέχεια να παρακάμψετε μη αυτόματα το προφίλ διαμόρφωσης παρέχοντας ένα -Dspring.profiles.active=prod παράμετρος στο JVM. Εναλλακτικά, μπορείτε επίσης να ορίσετε τη μεταβλητή περιβάλλοντος του λειτουργικού σας συστήματος στο επιθυμητό προεπιλεγμένο προφίλ.
Η σωστή χρήση της έγχυσης εξάρτησης με το Spring σημαίνει ότι επιτρέπεται η σύνδεση όλων των αντικειμένων σας με σάρωση όλων των επιθυμητών τάξεων διαμόρφωσης. Αυτό αποδεικνύεται χρήσιμο για την αποσύνδεση των σχέσεων και επίσης καθιστά ευκολότερη τη δοκιμή. Αντί για στενά μαθήματα ζεύξης κάνοντας κάτι τέτοιο:
public class TopTalentController { private final TopTalentService topTalentService; public TopTalentController() { this.topTalentService = new TopTalentService(); } } Επιτρέπουμε στην Άνοιξη να κάνει την καλωδίωση για εμάς:
public class TopTalentController { private final TopTalentService topTalentService; public TopTalentController(TopTalentService topTalentService) { this.topTalentService = topTalentService; } } Η συζήτηση του Misko Hevery στο Google εξηγεί σε βάθος το «γιατί» της ένεσης εξάρτησης, οπότε ας δούμε πώς χρησιμοποιείται στην πράξη. Στην ενότητα σχετικά με τον διαχωρισμό των ανησυχιών (Κοινά λάθη # 3), δημιουργήσαμε μια κατηγορία υπηρεσιών και ελεγκτή. Ας υποθέσουμε ότι θέλουμε να δοκιμάσουμε τον ελεγκτή υπό την προϋπόθεση ότι TopTalentService συμπεριφέρεται σωστά. Μπορούμε να εισαγάγουμε ένα πλαστό αντικείμενο στη θέση της πραγματικής εφαρμογής υπηρεσίας παρέχοντας μια ξεχωριστή κλάση διαμόρφωσης:
@Configuration public class SampleUnitTestConfig { @Bean public TopTalentService topTalentService() { TopTalentService topTalentService = Mockito.mock(TopTalentService.class); Mockito.when(topTalentService.getTopTalent()).thenReturn( Stream.of('Mary', 'Joel').map(TopTalentData::new).collect(Collectors.toList())); return topTalentService; } } Στη συνέχεια, μπορούμε να εγχύσουμε το πλαστό αντικείμενο λέγοντας στο Spring να χρησιμοποιήσει SampleUnitTestConfig ως προμηθευτής διαμόρφωσης:
@ContextConfiguration(classes = { SampleUnitTestConfig.class }) Αυτό μας επιτρέπει στη συνέχεια να χρησιμοποιήσουμε τη διαμόρφωση περιβάλλοντος για να εισάγουμε το προσαρμοσμένο φασόλι σε δοκιμή μονάδας.
Παρόλο που η ιδέα της δοκιμής μονάδας είναι εδώ και πολύ καιρό, πολλοί προγραμματιστές φαίνεται να «ξεχνούν» να το κάνουν αυτό (ειδικά αν δεν απαιτείται ή απλώς προσθέστε το ως μεταγενέστερη σκέψη. Αυτό προφανώς δεν είναι επιθυμητό, δεδομένου ότι οι δοκιμές δεν πρέπει μόνο να επαληθεύουν την ορθότητα του κώδικα σας, αλλά και να χρησιμεύουν ως τεκμηρίωση σχετικά με τον τρόπο συμπεριφοράς της εφαρμογής σε διαφορετικές καταστάσεις.
Όταν δοκιμάζετε υπηρεσίες ιστού, σπάνια κάνετε αποκλειστικά «καθαρές» δοκιμές μονάδας, καθώς η επικοινωνία μέσω HTTP συνήθως απαιτεί από εσάς να επικαλεστείτε την άνοιξη DispatcherServlet και δείτε τι συμβαίνει όταν μια πραγματική HttpServletRequest λαμβάνεται (καθιστώντας το ένα ενσωμάτωση δοκιμή, ασχολείται με επικύρωση, σειριοποίηση κ.λπ.). Μείνε ήσυχος , ένα Java DSL για εύκολο έλεγχο των υπηρεσιών REST, πάνω από το MockMVC, έχει αποδειχθεί ότι δίνει μια πολύ κομψή λύση. Εξετάστε το ακόλουθο απόσπασμα κώδικα με ένεση εξάρτησης:
@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = { Application.class, SampleUnitTestConfig.class }) public class RestAssuredTestDemonstration { @Autowired private TopTalentController topTalentController; @Test public void shouldGetMaryAndJoel() throws Exception { // given MockMvcRequestSpecification givenRestAssuredSpecification = RestAssuredMockMvc.given() .standaloneSetup(topTalentController); // when MockMvcResponse response = givenRestAssuredSpecification.when().get('/toptal/get'); // then response.then().statusCode(200); response.then().body('name', hasItems('Mary', 'Joel')); } } SampleUnitTestConfig καλώδια μια πλαστή εφαρμογή του TopTalentService σε TopTalentController ενώ όλες οι άλλες κατηγορίες είναι ενσύρματες χρησιμοποιώντας την τυπική διαμόρφωση που συνάγεται από τα πακέτα σάρωσης που έχουν τις ρίζες τους στο πακέτο κλάσης εφαρμογών. RestAssuredMockMvc χρησιμοποιείται απλώς για να δημιουργήσει ένα ελαφρύ περιβάλλον και να στείλει ένα GET αίτημα προς το /toptal/get τελικό σημείο
Η Άνοιξη είναι ένα ισχυρό πλαίσιο που είναι εύκολο να ξεκινήσετε, αλλά απαιτεί κάποια αφοσίωση και χρόνο για να επιτύχετε πλήρη γνώση. Αν αφιερώσετε χρόνο για να εξοικειωθείτε με το πλαίσιο, σίγουρα θα βελτιώσετε την παραγωγικότητά σας μακροπρόθεσμα και τελικά θα σας βοηθήσουμε να γράψετε καθαρότερο κώδικα και να γίνετε καλύτερος προγραμματιστής.
Εάν ψάχνετε περισσότερους πόρους, Άνοιξη σε δράση είναι ένα καλό πρακτικό βιβλίο που καλύπτει πολλά βασικά θέματα της Άνοιξης.
πώς να βρείτε τον αριθμό πιστωτικής κάρτας κάποιου
