Ik bestudeer ditboek (dat ik ten zeerste zou aanbevelen), en Ik ben in de war over hoe de auteurs uitleggen hoe het Spring-framework kan worden geconfigureerd.
Je kunt enkele codevoorbeelden zien die worden gebruikt in het boek hier. (Ze zijn voor iedereen beschikbaar.) De code waarnaar ik verwijs, is de code uit hoofdstuk 2, als je een kijkje wilt nemen.
In het boek staat dat er 3 manieren zijn om de Spring Container te configureren.
XML-gebaseerde configuratie
Hiervoor is een xml-bestand nodig dat er ongeveer zo uitziet:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" ...>
<bean id="accountService" class="com.wiley.beginningspring.ch2.AccountServiceImpl">
<property name="accountDao" ref="accountDao"/>
</bean>
<bean id="accountDao" class="com.wiley.beginningspring.ch2.AccountDaoInMemoryImpl">
</bean>
</beans>
En dan, om Spring op te starten, is de code die zal worden gebruikt:
ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("/com/wiley/beginningspring/ch2/ch2-beans.xml");
Ik heb op dit moment geen onduidelijkheden.
Java-gebaseerde configuratie
In deze configuratiemethode is er een klasse voor de configuratie als volgt:
@Configuration
public class Ch2BeanConfiguration {
@Bean
public AccountService accountService() {
AccountServiceImpl bean = new AccountServiceImpl();
bean.setAccountDao(accountDao());
return bean;
}
@Bean
public AccountDao accountDao() {
AccountDaoInMemoryImpl bean = new AccountDaoInMemoryImpl();
return bean;
}
}
en de code die verantwoordelijk is voor het bootstrappen van Spring ziet er als volgt uit:
ApplicationContext applicationContext
= new AnnotationConfigApplicationContext(Ch2BeanConfiguration.class);
Dus tot hier is alles duidelijk voor mij. (Een soort van…) Ik wil ook opmerken dat we hier een annotatie hebben die @Configuration heet…
Configuratie op basis van annotaties
De laatste beschikbare configuratiemethode, uitgelegd in het boek, is de Annotation Based Configuration.
Er is een XML-bestand zoals we hadden in de XML-gebaseerde configuratie, maar een veel kleinere:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" ...>
<context:component-scan base-package="com.wiley.beginningspring.ch2"/>
</beans>
Alle bonen hebben annotaties zoals:
@Component, @Service
enz..
En alle afhankelijkheden hebben de annotaties:
@Autowired
zodat bonen kunnen worden geïnjecteerd.
De manier waarop het Spring-framework wordt opgestart in deze configuratiemethode is als volgt:
ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("/ch2-beans.xml");
Dit zijn mijn vragen:
Waarom gebruikt de (zogenaamde) Annotation Based Configurationdaadwerkelijk ClassPathXmlApplicationContextmaar niet AnnotationConfigApplicationContexthierboven? Dit laatste lijkt veel geschikter om te worden gebruikt in een configuratie die de woorden “Annotation Based” bevat, nietwaar?
De Java-gebaseerde configuratiedie in het boek wordt uitgelegd, lijkt op wat zou moeten worden genoemd Annotatie-gebaseerde configuratie.?
En de manier waarop configuratie op basis van annotaties in het boek wordt uitgelegd, lijkt me eigenlijk zoiets als: op XML gebaseerde configuratie met Autowired-beans. Het heeft niet eens de @Configuration-annotatie, die de “Java-gebaseerde configuratie” heeft..
Hoeveel manieren zijn er om het Spring-framework te configureren?
Antwoord 1, autoriteit 100%
Om verwarring te voorkomen, moeten we begrijpen dat configuratiedefinitieen beandefinitietwee verschillende dingenzijn. Er zijn drie manieren om de configuratie te definiëren, standaard beschikbaar in Spring 4:
- xml-gebaseerdeconfiguratie, wanneer u de configuratie beschrijft in een xml-bestand;
- op Java gebaseerdeconfiguratie, wanneer de configuratie Java-klasse is, gemarkeerd met specifieke annotaties;
- op groovy gebaseerdeconfiguratie, wanneer de configuratie een bestand is met Groovy-code;
En er zijn twee manieren om boondefinities toe te voegen aan de applicatie:
-
configuratie binnenbean-definitie, wanneer u bonen handmatig toevoegt door declaratie in de configuratie.
In dit geval wordt de definitie gebaseerd op het configuratietype. Voor xml-config is dit de tag
<bean/>, voor op java gebaseerde config – methode met@Beanannotatie enbeans {...}constructie voor Groovy. -
op annotaties gebaseerdebonendefinitie, wanneer u bonenklassen markeert met specifieke annotaties (zoals
@Component,@Service,@Controllerenz.). Dit type configuratie maakt gebruik van classpath scanning.
In dit geval moet u de instructie specificeren voor het scannen van klassenpad. Voor xml-config is dit <context:component-scan base-package="..."/>, voor java-config – @ComponentScanannotatie, voor Groovy ctx.'component-scan'(...)aanroep.
Zoals je ziet, kun je configuraties en bonendefinities in verschillende combinaties gebruiken.
Merk op dat als u een op XML gebaseerde configuratie gebruikt, u een benadering kunt kiezen om afhankelijkheidsinjectie aan te sturen: handmatig in XML, of door annotaties te gebruiken (@Autowire, @Requiredenzovoort). In het laatste geval moet u <context:annotation-config/>definiëren. Maar verwar boondefinitie en afhankelijkheidsinjectiecontrole niet.
Laten we nu op basis van dit standpunt proberen uw vragen te beantwoorden:
Waarom gebruikt de (zogenaamde) op annotatie gebaseerde configuratie eigenlijk?
ClassPathXmlApplicationContext maar niet
AnnotationConfigApplicationContext hierboven?
De auteur van het boek heeft concepten door elkaar gehaald. Dit is eigenlijk een op XML gebaseerde configuratie met op annotaties gebaseerde bean-definitie.
De op Java gebaseerde configuratie die in het boek wordt uitgelegd, lijkt op wat
moet Annotation Based Configuration heten.?
Je hebt gelijk – op Java gebaseerde configuratie maakt echt actief gebruik van annotaties en zou annotatiegebaseerd kunnen worden genoemd. Maar annotatie is een onderdeel van Java. Bovendien is dit een traditionele term, gespecificeerd in documentatie.
Hoeveel manieren zijn er om het Spring-framework te configureren?
Dus standaard hebben we drie manieren om de configuratie te beschrijven en twee manieren om bonen te definiëren. Dat zijn zes manieren om het Spring-framework te configureren (standaard). Maar natuurlijk kunnen al deze manieren in combinatie met elkaar worden gebruikt.
Antwoord 2, autoriteit 18%
De gemakkelijkste manier om dit te begrijpen, is door in de lange geschiedenis van het raamwerk te kijken hoe dit is ontwikkeld.
-
XML-gebaseerde configuratie – deze was er vanaf het begin – versie 1 – zie javadoc voor ClassPathXmlApplicationContext. Dit was rond maart 2004, de tijd van J2EE 1.4, die een ENORME xml-configuratie had en Spring was een grote vereenvoudiging (ook XML, maar eenvoudiger). Dit gebruikt XML voor alles, inclusief het specificeren van autowiring, of welke afhankelijkheden waar direct naartoe gaan (uw ref=”acoundDao” voorbeeld).
-
Configuratie op basis van annotaties – in het voorjaar van 2.5 – dit kwam als een reactie op Java EE 5, nieuwe annotaties zoals @Autowiredwerden geïntroduceerd, was er nog steeds enige contextconfiguratie in XML-bestanden – meestal zou u definiëren welke pakketten om te worden gescand en de rest werd automatisch gedaan op basis van annotaties – vandaar de naam.
-
De op Java gebaseerde configuratie kwam met Spring 3 en is in latere versies verbeterd. Dit is wanneer AnnotationConfigApplicationContexten Configuratieannotatie werden geïntroduceerd – u zou XML mogelijk volledig kunnen laten vallen -> op java gebaseerde configuratie. Hoewel dit pas later praktisch werd met versie 4+, vanwege het grote aantal xml-helpertags voor aop, jdbc enz.
Naast deze 3 (2 eigenlijk omdat 1 en 2 dezelfde ApplicationContext-klasse gebruiken), zijn er andere manieren om een context te creëren:
- bekijk alle implementatieklassen van ApplicationContext-interface
- SpringJUnit4ClassRunnervoor junit-tests
- Ik wed dat er andere manieren zijn waarvan ik me niet bewust ben
Antwoord 3, autoriteit 12%
Ten eerste wil ik Ken Bekovbedanken voor zijn meer vindingrijke antwoord. Ik heb geprobeerd zijn antwoord te improviseren, zodat iedereen meer over dit gebied kan leren.
Configuratiedefinitie:
Spring 4 bevat 3 manieren om de configuratie te definiëren. Ze zijn
Voordelen van de annotatie:
-
Alle
information is in a single file(het is niet nodig om twee bestanden te openen om een bepaald gedrag te configureren) -
Als de klasse verandert,
no need to modify the xml file -
Annoments worden vaak als intuïtiever en robuuster beschouwd bij het herfactoren van applicatiecode. Ze profiteren ook van een betere IDE-begeleiding zoals die van guise biedt. Maar ze mixen applicatiecode met DI-zorgen. Een applicatie wordt afhankelijk van een framework. Een duidelijke scheiding is bijna onmogelijk.
Annotations are also limited when describing different injection behaviour at the same place (constructor, field) dependent on other circumstances (e.g. robot legs problem).Bovendien laten ze het niet toe om externe klassen te behandelen (bibliotheekcode) zoals je eigen bron. Daarom wordt aangenomen dat ze sneller werken dan XML.
Voordelen van xml-bestand:
-
Duidelijke scheiding tussen de POJO en zijn gedrag
-
Als je niet weet welke POJO verantwoordelijk is voor het gedrag, is het makkelijker om die POJO te vinden (zoeken in een subset van bestanden in plaats van de hele broncode)
-
XML heeft het enige voordeel van een declaratieve stijl die duidelijk gescheiden is van de applicatiecode zelf. Dat blijft onafhankelijk van DI-zorgen. De nadelen zijn
verbosity,poor re-factoringrobustnessena general runtime failure-gedrag. Er is slechts een algemene (XML) tool-ondersteuning met weinig voordeel vergeleken met IDE-ondersteuning voor b.v. Java. Daarnaast komt XML met prestatieoverhead, dus het is meestalslower than code solutions.
XML en op annotaties gebaseerde link:
- http://docs .spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-annotation-config
- Annotaties versus XML, voor- en nadelen
- Java-afhankelijkheidsinjectie: XML of annotaties
- Op lente-annotatie gebaseerde DI vs. xml-configuratie?
- Xml-configuratie versus op annotatie gebaseerde configuratie
Op Groovy gebaseerde link:
- https://objectpartners.com/2016/01 /12/using-groovy-based-spring-configuration/
- http://blog.andresteingress.com /2014/02/14/grails-java-based-spring-config/
Bean-definitie:
Er zijn 2 manieren om te bonen Definitie:
Klaspad scannen:
Voor xml-configis dit <context:component-scan base-package="..."/>, voor java- config– @ComponentScanannotatie, voor Groovy ctx.'component-scan'(...)aanroep.
Injectie met afhankelijkheid:
In op XML gebaseerde configuratie kan dependency injectionhandmatig worden gedaan in XML, of door annotationste gebruiken (@Autowire, @Required etc) . In dat geval is het nodig om <context:annotation-config/>
te definiëren
Vraag & Antwoord:
V1: Waarom gebruikt de (zogenaamde) op annotatie gebaseerde configuratie ClassPathXmlApplicationContext maar niet
AnnotationConfigApplicationContext hierboven?
Antwoord:het is een XML-gebaseerde configuratie met op annotaties gebaseerde bean-definitie.
Toepassingscontext:
AnnotationConfigApplicationContext:
1.AnnotationConfigApplicationContext en bovenliggende context
ClassPathXmlApplicationContext:
- http://www.tutorialspoint.com/spring/spring_applicationcontext_container.htm
- http://www.mkyong.com/spring3/spring -3-hallo-wereldvoorbeeld/
V2: De op Java gebaseerde configuratie die in het boek wordt uitgelegd, lijkt op wat op annotatie gebaseerde configuratie zou moeten worden genoemd.?
Antwoord:je hebt gelijk wat dat betreft. Op Java gebaseerde configuratie maakt gebruik van annotaties en wordt op annotatie gebaseerde configuratie genoemd. Maar annotatie is een enkel onderdeel van Java, niets anders.
Maar we moeten uitgebreid begrijpen hoe deze hiërarchie van XML naar op annotaties gebaseerd en uiteindelijk op groovy gebaseerd komt?
Een alternatief voor XML-configuraties wordt geboden door op annotaties gebaseerde configuraties die vertrouwen op de bytecode-metadata voor het bedraden van componenten in plaats van declaraties tussen haakjes. In plaats van XML te gebruiken om een bean-bedrading te beschrijven, verplaatst de ontwikkelaar de configuratie naar de componentklasse zelf door annotaties te gebruiken op de relevante klasse, methode of velddeclaratie. Zoals vermeld in de sectie met de naam “Voorbeeld: de RequiredAnnotationBeanPostProcessor”, is het gebruik van een BeanPostProcessor in combinatie met annotaties een gebruikelijke manier om de Spring IoC-container uit te breiden.
Bijvoorbeeld,
Spring 2.0introduceerde de mogelijkheid om vereiste eigenschappen af te dwingen met de annotatie @Required.
Spring 2.5maakte het mogelijk om dezelfde algemene benadering te volgen om de afhankelijkheidsinjectie van Spring te stimuleren. In wezen biedt de annotatie@Autowireddezelfde mogelijkheden als beschreven in Sectie 6.4.5, “Autowiring-medewerkers”maar met meer fijnmazige controle en bredere toepasbaarheid.
Spring 2.5heeft ook ondersteuning toegevoegd voor JSR-250-annotaties zoals @PostConstructen @PreDestroy.
Spring 3.0heeft ondersteuning toegevoegd voor JSR-330 (Dependency Injection for Java)-annotaties in het javax.inject-pakket, zoals @Injecten @Named. Details over die annotaties zijn te vinden in de relevante sectie.
Q3: Hoeveel manieren zijn er om het Spring-framework te configureren?
Antwoord:
Theoretically,3 manieren om configuratie te beschrijven en 2 manieren om bonen te definiëren. Het wordt 3*2 = 6 manieren om het Spring-framework te configureren (standaard). Al deze manieren kunnen in combinatie met elkaar worden gebruikt.
But Actually,kunnen we in één woord het lente-framework configureren met behulp van XMLof annotations.
4, Autoriteit 2%
De drie manieren om het veerkader te configureren, zijn helemaal niet bedoeld om wederzijds exclusief te zijn. Eigenlijk is mijn gok dat u gemiddeld ten minste twee bij elkaar zult vinden.
De op annotatie gebaseerde configuratie is de minst waarschijnlijk stand-alone, simpelweg omdat het afhankelijk is van metadata die inherent verspreid is in de broncode.
De AnnotationConfigApplicationContextkan worden gebruikt om een pureop annotaties gebaseerde contextop te starten, maar u moet alles doorgeven uw klassengeannoteerd als @Componentof afgeleiden, in plaats van door te geven in een enkele (of een paar) @Configuration-geannoteerde klasse(n) — die is meestal niet praktisch.
Hoewel dit vrijwel hetzelfde is als het statisch weergeven van de bonen in XML- of Java-configuratie, maakt het feit dat u dit in code moet doen wanneer u de toepassingscontext zelf bouwt het minder nuttig, omdat u dat niet kunt profiteren van de verschillende slimme manieren om automatisch een applicatiecontext te starten (in webcontexten enzovoort).
Daarom wil je waarschijnlijk in staat zijn om de volledige metadata van de objectgrafiek in één keer te verzamelen, en dat kan alleen worden bereikt met een XML- of een op Java gebaseerde configuratie, die afhankelijk is van ” gecentraliseerde” metagegevens die de hele objectgrafiek beschrijven.
Voor zowel XML- als Java-gebaseerde benaderingen kunnen deze “gecentraliseerde metadata” (<beans>of @Configuration) statisch worden gedefinieerd (met expliciete <bean>of @Beandefinities) of dynamisch (met behulp van <component-scan>of @ComponentScan). Het is dus redelijk om te zeggen dat deze twee benaderingen gewoon verschillende formaten zijn met vrijwel dezelfde mogelijkheden die beide kunnen profiteren van op annotaties gebaseerde configuraties voor het verzamelen van de “gedecentraliseerde” metadata.