Le design pattern MVC est un modèle de conception adapté à la séparation des couches.

Cette méthode impose de séparer présentation, traitements et données.

En respectant cette méthodologie, le travail en équipe sera facilité par le découpage des tâches et des fichiers. La maintenance du code sera améliorée du fait de sa spécialisation. Bref, que des avantages.

Le Framework Spring implémente ce design pattern.

Dans cet article qui lui est consacré, nous allons mettre en pratique cette séparation des couches en utilisant un MultiActionController, qui me semble plus simple pour commencer.

DispatcherServlet

Point d’entrée de l’application, le DispatcherServlet effectue le premier mapping de l’application, il distribue les requêtes aux servlets correspondantes.

exemple : /servlet1/* sera renvoyé vers la servlet 1

Toutes les urls de notre application commençant par servlet1 seront « dispatchées » vers cette servlet

Cette configuration est effectuée dans le web.xml :

    <servlet>
        <servlet-name>introduction-spring</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>introduction-spring</servlet-name>
        <url-pattern>/servlet1/*</url-pattern>
    </servlet-mapping>

SimpleUrlHandlerMapping

Il fait la correspondance entre les urls transmises par la servlet et les controllers adéquats.

/servlet1/controller1/*

Toutes les urls correspondant à ce pattern seront alors mappées à notre controller1

Fichier introduction-spring-servlet.xml :

<bean id="“urlMapping”" class="“org.springframework.web.servlet.handler.SimpleUrlHandlerMapping”">
  <property name="“mappings”">
   <props>
     <prop key="“/controller1/*”">controller1</prop>
   </props>
</property>
</bean>

MultiActionController

Nous voilà enfin au cœur du sujet, un controller de type MultiActionController est en fait un controller dont les méthodes seront lancées en fonction des urls d’entrées. Pour effectuer cette correspondance, nous utiliserons un PropertiesMethodNameResolver.

<bean id="“controller1″" class="“com.cestpasdur.controllers.IndexController”">
  <property name="“methodNameResolver”" ref="“methodNameResolver”"></property>
</bean>

PropertiesMethodNameResolver

Effectue la correspondance entre les requêtes entrantes et les méthodes du controller.

Dans notre cas, /controller1/etat1.htm correspond à la méthode etat1Handler de notre controller tandis que /controller1/etat2.htm, à etat2Handler

<bean id="“methodNameResolver”" class="“org.springframework.web.servlet.mvc.multiaction.PropertiesMethodNameResolver”">
  <property name="“mappings”">
    <props>
       <prop key="“/controller1/etat1.htm”">etat1Handler</prop>
       <prop key="“/controller1/etat2.htm”">etat2Handler</prop>
    </props>
  </property>
</bean>

InternalResourceViewResolver

Il vaut mieux ne pas rendre accessible les jsp directement, celles ci-doivent être dans un répertoire non disponible à la navigation (par opposition aux images et CSS par exemple), dans notre cas : /WEB-INF/vues/* Il n’y aura que les controllers qui pourront y accèder.

Afin d’éviter de coder ce paramètrage en dur dans notre controller, Spring met à notre disposition un resolver de view.

Le handler de notre controller doit retourner un objet de type ModelAndView, celui-ci s’instancie (entre autre) de la manière suivante :

...
return new ModelAndView(“vue1″) ;
...

Le rôle de notre resolveur de view, sera de faire correspondre cette vue à une jsp.

La config est la suivante :

<bean id="jspViewResolver" class="“org.springframework.web.servlet.view.InternalResourceViewResolver”">
  <property name="“prefix”" value="“/WEB-INF/vues/”"></property>
  <property name="“suffix”" value="“.jsp”"></property>
</bean>

Demander la vue1 revient à demander le fichier /WEB-INF/vues/vue1.jsp. Notre controlleur n’a pas donc pas à se soucier de l’emplacement réél des jsp.

Conclusion

Le MultiActionController sera utilisé de préférence pour afficher des pages appelant ou non une base de données.

Pour des pages nécessitant un affichage, soumission ou validation de formulaire, vous devrez vous orienter vers des contrôleurs du type SimpleFormController ou webflow.