Der ApplicationContext ist eine Obermenge der BeanFactory. Während eine BeanFactory Spring Beans instanziiert und konfiguriert, bietet der ApplicationContext zusätzlich die Unterstützung von Spring AOP, Message Resource Handling (Internationalisierung) und Event-Verarbeitung an. Ferner lassen sich über den ApplicationContext relativ einfach applikationsschichtspezifische Kontexte integrieren. Daher ist es empfehlenswert, den ApplikationsContext der BeanFactory vorzuziehen.

Die BeanFactory ist der IoC (Inversion of Control) Container im Spring Framework. 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 Komponenten (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 XmlBeanFactory zur Verfügung.
Beispiel:

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

  XmlBeanFactory beanFactory = 
   new XmlBeanFactory(
    new ClassPathResource("beanDefinitions.xml"));

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

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

• Abhängigkeiten werden an einer zentralen Stelle deklariert 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 die das Framework bzw. der Container zur Laufzeit Informationen in die Komponenten injiziert ober bestimmtes Verhalten (über Methodenaufrufe) auslöst.

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.

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 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.

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.

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>

  <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 (Singleton oder nicht Singleton)
• Referenzen auf andere Beans
• Konstruktor-Argumente

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

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 per Spring IoC-container
• Prototype: Bei 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

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

BeanNameViewResolver
Die View wird unter dem entsprechenden Namen als Bean im ApplikationContext 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.