Da in vielen Antworten bereits angegeben ist, wofür diese Anmerkungen verwendet werden, konzentrieren wir uns hier auf einige geringfügige Unterschiede zwischen ihnen.
Zuerst die Ähnlichkeit
Der erste Punkt, der noch einmal hervorgehoben werden sollte, ist, dass in Bezug auf die automatische Erkennung von Scans und die Abhängigkeitsinjektion für BeanDefinition alle diese Anmerkungen (d. H. @Component, @Service, @Repository, @Controller) gleich sind. Wir können eins anstelle des anderen verwenden und uns trotzdem zurechtfinden.
Unterschiede zwischen @Component, @Repository, @Controller und @Service
@Komponente
Dies ist eine allgemeine Stereotypanmerkung, die angibt, dass die Klasse eine Federkomponente ist.
Das Besondere an @Component ist, dass
<context:component-scan> nur gescannt@Component und nicht gesucht wird@Controller ,@Serviceund@Repositoryim Allgemeinen. Sie werden gescannt, weil sie selbst mit Anmerkungen versehen sind@Component.
Werfen Sie einen Blick auf @Controller, @Serviceund @RepositoryAnnotation Definitionen:
@Component
public @interface Service {
….
}
@Component
public @interface Repository {
….
}
@Component
public @interface Controller {
…
}
Daher ist es nicht falsch, das zu sagen @Controller, @Serviceund @Repositoryes handelt sich um spezielle Arten von @ComponentAnmerkungen. <context:component-scan>nimmt sie auf und registriert ihre folgenden Klassen als Bohnen, als ob sie mit Anmerkungen versehen wären @Component.
Spezielle Typanmerkungen werden ebenfalls gescannt, da sie selbst mit @ComponentAnmerkungen versehen sind, was bedeutet, dass sie auch @Components sind. Wenn wir unsere eigene benutzerdefinierte Anmerkung definieren und sie mit Anmerkungen versehen @Component, wird sie auch mit gescannt<context:component-scan>
@Repository
Dies soll anzeigen, dass die Klasse ein Datenrepository definiert.
Was ist das Besondere an @Repository?
Neben dem Hinweis, dass es sich um eine auf Anmerkungen basierende Konfiguration handelt , besteht @Repositorydie Aufgabe darin, plattformspezifische Ausnahmen abzufangen und sie als eine der einheitlichen, nicht aktivierten Ausnahmen von Spring erneut auszulösen. Dafür erhalten wir Folgendes PersistenceExceptionTranslationPostProcessor, das wir im Anwendungskontext unseres Spring wie folgt hinzufügen müssen:
<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>
Dieser Bean-Postprozessor fügt jedem Bean, mit dem Anmerkungen versehen sind, einen Advisor hinzu, @Repositorysodass plattformspezifische Ausnahmen abgefangen und dann als eine der ungeprüften Datenzugriffsausnahmen von Spring erneut ausgelöst werden.
@Regler
Die @ControllerAnmerkung gibt an, dass eine bestimmte Klasse die Rolle eines Controllers übernimmt. Die @ControllerAnnotation fungiert als Stereotyp für die annotierte Klasse und gibt ihre Rolle an.
Was ist das Besondere an @Controller?
Wir können diese Anmerkung nicht durch eine andere wie @Serviceoder @Repositoryersetzen, obwohl sie gleich aussieht. Der Dispatcher durchsucht die @Controllermit @RequestMappingAnmerkungen versehenen Klassen und erkennt Methoden, die mit Anmerkungen versehen sind. Wir können verwenden @RequestMappingnur auf / in jenen Methoden , deren Klassen mit annotiert , @Controllerund es wird nicht funktionieren mit @Component, @Service, @Repositoryetc ...
Hinweis: Wenn eine Klasse bereits als Bohne durch jede andere Methode registriert ist, wie durch @Beanoder durch @Component, @Serviceusw ... Anmerkungen, dann @RequestMappingkönnen ausgewählt werden , wenn die Klasse auch mit Anmerkungen versehen ist @RequestMappingAnmerkung. Aber das ist ein anderes Szenario.
@Bedienung
@Service Beans enthalten die Geschäftslogik und die Aufrufmethoden in der Repository-Schicht.
Was ist das Besondere an @Service?
Abgesehen von der Tatsache, dass es verwendet wird, um anzuzeigen, dass es die Geschäftslogik enthält, ist in dieser Anmerkung nichts anderes erkennbar. Aber wer weiß, der Frühling könnte in Zukunft einige zusätzliche Ausnahmen hinzufügen.
Was sonst?
Ähnlich wie oben, in der Zukunft hinzufügen Frühling können spezielle Funktionalitäten für @Service, @Controllerund @Repositoryauf der Grundlage ihrer Schichtung Konventionen. Daher ist es immer eine gute Idee, die Konvention zu respektieren und sie in Übereinstimmung mit Ebenen zu verwenden.
