Est-ce une mauvaise pratique de placer le code de vue dans le contrôleur?

Question

Dans MVC (tels que JSP et Spring), est-il une mauvaise pratique d'afficher le code associé dans le contrôleur?

Dans mon cas, le contrôleur effectue un certain travail, puis transmet les résultats à la vue (JSP). Dans le cas d'un message d'état, je peux passer le texte entier du message à la vue, ou passer une clé et laisser le JSP le mapper au texte du message.

Exemple:

message généré dans le contrôleur

Controller Spring:

protected ModelAndView onSubmit(...) { 
    Map map = new HashMap(); 
    // Controller processing 
    if (...) 
     map.put("status", "Case 1 status message"); 
    else 
     map.put("status", "Case 2 status message"); 
    return new ModelAndView("viewPage", map); 
} 

JSP:

{$status} 

message généré en vue

Controller Spring:

protected ModelAndView onSubmit(...) { 
    Map map = new HashMap(); 
    // Controller processing 
    if (...) 
     map.put("status", "case1"); 
    else 
     map.put("status", "case2"); 
    return new ModelAndView("viewPage", map); 
} 

JSP:

<c:choose> 
    <c:when test="{$status eq 'case1'}">Case 1 status message</c:when> 
    <c:when test="{$status eq 'case2'}">Case 2 status message</c:when> 
</c:choose> 

Dans le premier cas, le contrôleur et le code JSP est plus simple, mais il y a une logique liée est vue dans le contrôleur. Dans le second cas, toute la logique d'affichage est dans la JSP, mais le code n'est pas aussi simple. Est-ce que je viole le paradigme MVC en générant du texte de message dans le contrôleur? Quelle est la pratique courante pour ce scénario?

Answer 1

La combinaison de code d'interface utilisateur et de contrôleur dans MVC est une pratique courante dans les clients enrichis (dans Swing par exemple). même dans le web MVC il est parfois implémenté, pour des réponses très simples.

Dans votre cas, ce que vous faites n'est pas recommandé. Habituellement, vous mettez les textes de votre application dans un resource bundle en utilisant le mécanisme MessageSource du ressort, et vous y référer uniquement en utilisant des codes. Le regroupement de ressources est un des propriétés simples fichier, dans votre cas, il ressemblera à ceci:

case1=Case 1 status message 
case2=Case 2 status message 

Dans la JSP vous faites référence à l'aide de la balise de la manière suivante:

<spring:message message="${status}"/> 

faisceaux de ressources ont deux avantages:

• il est facile à internationaliser votre site et fournir en plusieurs langues
• Vous pouvez gérer les textes d'application en externe à la source, et si vous utilisez le ReloadableResourceBundleMessageSource du ressort, vous pouvez même modifier les textes sans redéployer l'application.

Answer 2

La pratique courante consiste à utiliser des regroupements de ressources :-) Vous pouvez les configurer comme message sources dans votre contexte Spring et utiliser la balise message pour les récupérer.

Answer 3

Je ne pense pas que ce soit une mauvaise pratique.Une bonne stratégie pour décider si mettre une certaine logique dans la vue ou dans le contrôleur serait d'imaginer un scénario où vous auriez deux moteurs de vue différents. Ensuite, vous pouvez vérifier si ce code particulier ne serait pas répété dans les deux moteurs de vue. Par exemple, supposons que vous ayez le même contrôleur, mais un rendu de vue alternatif, disons, un convertisseur qui génère une feuille de calcul Excel.

Dans votre exemple, vous devez placer la logique de récupération du bon message non seulement dans le JSP (qui rend HTML), mais aussi dans la feuille de calcul Excel (sous forme de formule). Pour résumer, l'exemple que vous avez donné représente une logique agnostique donc le contrôleur est un bon endroit pour cela.

Cela ne s'applique pas à une logique, par exemple, qui décide si un texte particulier doit être rendu en gras ou non. C'est la logique spécifique à la vue. HTML utilise sylesheets pour afficher du texte en gras alors que d'autres moteurs de vue utilisent une représentation différente. Dans ce cas, le meilleur endroit pour maintenir cette logique serait la couche de vue (JSP pour les vues HTML et etc.)