Ist es eine schlechte Übung, View-Code in den Controller zu schreiben?

Question

In MVC (wie JSP und Spring), ist es schlechte Praxis, verwandten Code im Controller zu sehen?

In meinem Fall führt der Controller etwas Arbeit aus und übergibt dann die Ergebnisse an die Ansicht (JSP). Im Falle einer Statusnachricht kann ich den gesamten Nachrichtentext an die Ansicht übergeben oder einen Schlüssel übergeben und von der JSP dem Nachrichtentext zuordnen.

Beispiel:

Nachricht erzeugt in Controller

Frühling Controller:

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} 

Nachricht im Hinblick erzeugt

Frühling Controller:

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> 

Im ersten Fall ist die Steuerung und JSP-Code einfacher, aber es gibt Ansicht Logik in der Steuerung zusammen. Im zweiten Fall ist die View-Logik in der JSP, aber der Code ist nicht so einfach.

Verstehe ich das MVC-Paradigma, indem ich Nachrichtentext im Controller erzeuge? Was ist die übliche Praxis für dieses Szenario?

Answer 1

Die Kombination von UI- und Controller-Code in MVC ist in Rich Clients (z. B. in Swing) üblich. sogar im Web MVC wird manchmal implementiert, für sehr einfache Antworten.

In Ihrem Fall wird jedoch nicht empfohlen, was Sie tun. Normalerweise setzen Sie die Texte Ihrer Anwendung in eine resource bundle unter Verwendung der Feder MessageSource Mechanismus, und beziehen sich nur über Codes. Das Ressourcenpaket ist eine einfache Eigenschaften in Ihrem Fall Datei, wird es wie folgt aussehen:

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

In der JSP verweisen Sie auf den -Tag in der folgenden Weise unter Verwendung von:

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

Ressourcenbündel haben zwei Vorteile:

• es ist leicht, Ihre Website zu internationalisieren und bieten sie in mehreren Sprachen
• Sie können die Anwendungstexte extern zur Quelle verwalten, und wenn Sie spring ReloadableResourceBundleMessageSource verwenden, können Sie sogar die Texte ändern, ohne die Anwendung erneut zu installieren.

Answer 2

Die übliche Praxis ist, Ressourcen-Bundles zu verwenden :-) Sie können sie als message sources in Ihrem Spring-Kontext konfigurieren und message-Tag verwenden, um sie abzurufen.

Answer 3

Ich glaube nicht, dass es eine schlechte Praxis ist.Eine gute Strategie, um zu entscheiden, ob Sie etwas Logik in die Ansicht oder in den Controller setzen, wäre ein Szenario, in dem Sie zwei verschiedene View Engines hätten. Dann können Sie prüfen, ob dieser bestimmte Code in den beiden View Engines nicht wiederholt wird.

Nehmen wir beispielsweise an, Sie hätten den gleichen Controller, aber einen alternativen Renderer, sagen wir, einen Renderer, der eine Excel-Tabelle generiert.

In Ihrem Beispiel müssten Sie die Logik zum Abrufen der richtigen Nachricht nicht nur in der JSP (die HTML rendert), sondern auch in der Excel-Tabelle (als Formel) platzieren.

Zusammenfassend stellt das von Ihnen angegebene Beispiel eine Logik dar, die view agnostic darstellt, daher ist der Controller ein guter Platz dafür.

Es würde nicht für eine Logik gelten, die zum Beispiel entscheidet, ob ein bestimmter Text fett dargestellt werden soll oder nicht. Dies ist eine Ansichtsspezifische Logik. HTML verwendet Syle Sheets zum Rendern von fettem Text, während andere View Engine eine andere Darstellung verwendet. In diesem Fall wäre der beste Ort, um diese Logik zu halten, die Ansichtsebene (JSP für HTML-Ansichten usw.).