<beans ...
xmlns:ct="http://www.springframework.org/schema/context"
...>
  <ct:annotation-config/>
  <ct:component-scan base-package="org.example"/>
  ...
</beans>

Das Beispiel veranlasst Spring beim Start alle Klassen in org.example nach Annotationen abzusuchen. Ein Beispiel, um eine Komponente mittels Annotation zu registrieren:

 
@Service("example")
public class Example {
  ...

Daher ist es empfehlenswert, den ApplikationsContext der BeanFactory vorzuziehen.

Ein Beispiel für das manuelle Erzeugen eines ApplicationContext aus einer Konfigurations-Datei:

 
public class ClassPathXmlApplicationContextExample {
 public static main(String[] args) {

  ClassPathXmlApplicationContext applicationContext =
   new ClassPathXmlApplicationContext(
    "beanDefinitions.xml");

  BundesligaManager blManager = 
   applicationContext.getBean("bundesligaManager",
    BundesligaManager.class);
  List<Team> teams = blManager.listTeams();
 }
} 
 

• Logging
• Audit
• Performancemessung
• Transaktions-Verwaltung

Sie verwaltet die Komponenten (Spring-Beans) sowie deren Abhängigkeiten und fungiert als Schnittstelle zwischen einer Applikation und dem Spring-IoC-Container.

Eine Applikation greift auf das Spring-Framework zu, indem ein BeanFactory-Objekt (Objekt, welches das BeanFactory-Interface implementiert) instanziiert wird. Danach kann über dieses Objekt auf die Spring-Beans, die vom Spring-Container verwaltet werden, zugegriffen werden.

Die Konfiguration einer BeanFactory kann programmatisch erfolgen. In den meisten Fällen erfolgt die Konfiguration allerdings über ein externes Konfigurationsfile (Property-Datei oder XML-Datei). Für komplexere Applikationen sollte man die Konfiguration über XML vorziehen.

Das Spring-Framework stellt hierfür die Klasse XmlBeanDefinitionReader zur Verfügung, die die Konfiguration in eine BeanFactory laden kann.
Beispiel:

 
public class XmlBeanDefinitionReaderExample {
 public static main(String[] args) {

  DefaultListableBeanFactory beanFactory = 
   new DefaultListableBeanFactory();
  XmlBeanDefinitionReader definitionReader = 
   new XmlBeanDefinitionReader(beanFactory);
  definitionReader.loadBeanDefinitions(
   new ClassPathResource("beanDefinitions.xml"));

  BundesligaManager blManager = 
   beanFactory.getBean("bundesligaManager",
    BundesligaManager.class);
  List<Team> teams = blManager.listTeams();
 }
} 
 

Anmerkung: In den meisten Anwendungen ist ein ApplicationContext einer BeanFactory vorzuziehen. Dieser erweitert die BeanFactory und stellt noch weitere Funktionalität zu Verfügung.

Somit übernimmt das Framework die Aufgabe des Erzeugens von Objekten und deren Abhängigkeiten. Dies hat folgende Vorteile:

• Abhängigkeiten können an einer zentralen Stelle deklariert werden und sind nicht hart im Code verdrahtet
• Steigerung der Flexibilität. Komponenten können ausgetauscht werden, ohne den Code neu kompilieren zu müssen
• Die Komponenten eines Systems werden entkoppelt. Eine Komponente ist von einem Interface einer anderen Komponente und nicht von konkreten Klassen abhängig
• Erleichtert das Testen

Es dient als zentrale Anlaufstelle für einkommende Requests und delegiert diese an eine Klasse, die das Controller-Interface implementiert. Über ein sogenanntes HandlerMapping wird definiert, welche Controller-Klasse für einen spezifischen Request zuständig ist.

Der Rückgabewert einer Spring-Controller-Methode ist ein Objekt der ModelAndView Klasse. Dieses Objekt referenziert ein View- und ein Modelobjekt.

Ein Modelobjekt implementiert das Map-Interface. Das Viewobjekt implementiert das View-Interface, welches eine render-Methode besitzt, die den darzustellenden Inhalt generiert.

In Spring wird mit Hilfe von HandlerMappings die URL eines Requests auf eine Ausführungskette für die Requestabarbeitung gemappt. Die Ausführungskette besteht aus einer Liste von Pre- und Postprozessoren sowie Controller-Objekte.

Spring bietet drei verschiedene Implementierungen des HandlerMapping Interface an:

BeanNameUrlHandlerMapping:
Der Beanname des aufzurufenden Controllers wird über die URL des Requests identifiziert. Wildcards werden nicht unterstützt. Beispiel: Eine URL “/item/index.html” wird durch den BeanNameUrlHandlerMapping auf eine (Controller-)SpringBean mit der ID “/item/index.html” gemappt.

SimpleUrlHandlermapping:
Bei der Konfiguration des Mappings kann Ant-Syntax für die URL Pfadangabe benutzt werden.

ControllerClassNameHandlerMapping:
Pfad der URL wird vom Klassenname des Controllers abgeleitet (seit Spring 2.5).

In jeder HandlerMapping-Definition können ein oder mehrere HandlerInterceptor-Klassen definiert werden. Mit Hilfe von HandlerInterceptor-Klassen sollte Funktionalität implementiert werden, die für alle URLs eines HandlerMappings aufgerufen werden soll. Dies vermeidet redundanten Code in den Controller-Klassen.

Dies bedeutet, dass das Framework von seinen Komponenten verlangt, dass bestimmte Callback-Methoden durch sie implementiert werden. Über diese kann das Framework bzw. der Container zur Laufzeit Informationen in die Komponenten injiziert ober bestimmtes Verhalten (über Methodenaufrufe) auslösen.

Bei Spring kommt eine spezialisierte Form von IoC zum Einsatz, auch wenn es im Detail sehr wohl Unterschiede gibt (siehe hierzu auch Dependency Injection). Im Kontext von Spring wird IoC und Dependency Injection vielfach synonym verwendet.

• Model: Daten, die vom System verwaltet und angezeigt werden
• View: Komponenten eines Systems, die für die Anzeige der Daten verantwortlich sind
• Controller: Steuerungs-Komponente, die Anfragen entgegen nimmt, Geschäftslogik aufruft und relevante Daten dem View zur Anzeige übergibt

Spring implementiert mit dem Spring MVC Framework das MVC Pattern.

Durch den BeanScope kann beispielsweise festgelegt werden, ob der Spring IoC-Container immer die gleiche Instanz einer SpringBean liefert oder jedemal ein neues SpringBean-Objekt erzeugt, wenn die Applikation über den Container auf eine SpringBean zugreift. Neben der Erzeugung und dem Abräumen von Beans wird somit auch der Gültigkeitsbereich der Objekte deklarativ gesteuert und muss nicht programmiert werden. Spring kennt folgende Scopes:

• Singleton:Für eine Spring Bean erzeugt der IoC-Container genau eine Objekt-Instanz. Dies ist der Default-Scope und ist auch als “Application Scope” bekannt.
• Prototype: Bei jedem Zugriff über den IoC-Container wird stets ein neues Objekt erzeugt
• Request: Nur bei Webanwendungen. Für den Lebenszeitraum eines Requests wird immer die Objekt-Instanz verwendet
• Session: Nur bei Webanwendungen. Für den Lebenszeitraum einer Session wird immer die Objekt-Instanz verwendet
• Global-Session: Nur bei Portlet-Anwendungen. Für den Lebenszeitraum einer globalen Session wird immer die gleiche Objekt-Instanz verwendet
• Bundle: Nur bei OSGi Service Platform: Es wird für jedes Bundle eine eigene Instanz erzeugt.

Spring Beans sind Geschäftsobjekte/Komponenten, die für eine Applikation benötigt werden. Hierbei handelt es u.a. um:

• Service Objekte: stellen Service Methoden zur Verfügung
• Data Access Objekte (DAO): kapseln den Datenzugriff
• Infrastrukturelle Objekte: Hibernate Session Factories, JMS Queues, etc.
  
  

Die Konfiguration erfolgt in einer XML- oder Property-Datei. Aus Gründen der Lesbarkeit empfiehlt sich die Verwendung von XML.

Beispiel:

  
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="...">
  <bean id="..." class="...">
   <!— Bean Konfiguration -->
  </bean>
  <!-- weitere Bean Konfigurationen -->
</beans>
 

Eine Bean-Definition definiert u.a. folgende Metadaten:

• Eindeutige ID einer Bean
• Klassenname (kompletter Package Pfad)
• Scope einer Bean
• Referenzen auf andere Beans
• Konstruktor-Argumente

Die komplette Liste der Metadaten ist in der Spring Dokumentation beschrieben.

Anmerkung: Domain-Objekte sollten nicht als Spring Beans definiert werden. Sie werden über DAOs und Geschäftslogik angelegt und benutzt. Dem Spring IoC-Container wird durch Konfigurations-Metadaten mitgeteilt, wie diese Beans zu instanziieren und zu verknüpfen sind.

 
  @Secured({"ROLE_ADMIN"})
  public void doSomething() {
   ...
  }
 

Das Model repräsentiert die Daten, die einem Benutzer angezeigt werden sollen. Hierbei handelt es sich in den meisten Fällen um JavaBeans, die in einer Map abgelegt sind.

Die View hat die Aufgabe, die Daten aus dem Model zu rendern (anzuzeigen). Bei einer Web-Applikation wird hierbei in der Regel HTML-Output generiert, der vom Browser interpretiert und angezeigt wird. In Spring MVC ist eine View eine Klasse, die das Interface View implementiert.

Der Controller ist für die Abarbeitung eines Requests verantwortlich. Er sorgt dafür, dass das Model erzeugt wird und übergibt dieses im Anschluss and die View für die Anzeige. Ein Spring MVC Controller implementiert das Interface Controller. Eine zentrale Komponente der MVC Implementierung von Spring ist das DispatcherServlet.

Spring Web Flow basiert auf dem Modell eines endlichen Automaten, ist also für Anwendungsfälle mit definierten Start- und Endzustand geeignet.

Neben Spring Web MVC werden Spring Portlet MVC und andere Frameworks für Webanwendungen wie z.B. JSF unterstützt.

Das Spring Framework enthält folgende Implementierungen des ViewResolver-Interface:

BeanNameViewResolver
Die View wird unter dem entsprechenden Namen als Bean im ApplicationContext gesucht. Keine Unterstützung von Internationalisierung.

ResourceBundleViewResolver
Das View-Mapping wird in eine separate Property-Datei ausgelagert. Internationalisierung wird unterstützt.

URLBasedViewResolver
Der View-Name wird über eine URL aufgelöst.

XmlViewResolver
View-Definitionen werden in einem separaten XML-File vorgenommen. Internationalisierung wird nicht unterstützt.