Это плохая практика, чтобы поместить код представления в контроллер?

Question

В MVC (например, JSP и Spring) плохая практика для просмотра связанного кода в контроллере?

В моем случае контроллер выполняет некоторую работу, а затем передает результаты в представление (JSP). В случае сообщения о состоянии я могу передать весь текст сообщения представлению или передать ключ и позволить JSP сопоставить его с текстом сообщения.

Пример:

Сообщение, сгенерированное в контроллере

Пружинный контроллер:

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}

Сообщение, сгенерированное в представлении

Пружинный контроллер:

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>

В первом случае контроллер и код JSP проще, но в контроллере есть логика, связанная с просмотром. Во втором случае вся логика представления находится в JSP, но код не так прост.

Я нарушаю парадигму MVC, генерируя текст сообщения в контроллере? Какова общая практика для этого сценария?

Answer 1

Обычной практикой является использование комплектов ресурсов :-) Вы можете настроить их как источники сообщений в контексте Spring и использовать тег message для их получения.

Answer 2

Объединение кода пользовательского интерфейса и контроллера в MVC является обычной практикой в ​​Rich Clients (например, в Swing). даже в Web MVC это иногда реализуется для очень простых ответов.

В вашем случае, однако, то, что вы делаете, не рекомендуется. Обычно вы помещаете тексты вашего приложения в пакет ресурсов , используя механизм Spring MessageSource , и ссылаетесь на него только с помощью кодов. Пакет ресурсов - это простой файл свойств, в вашем случае он будет выглядеть так:

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

В JSP вы ссылаетесь на него, используя тег следующим образом:

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

Пакеты ресурсов имеют два преимущества:

• Легко интернационализировать ваш сайт и предоставлять его на нескольких языках
• Вы можете управлять текстами приложения извне источника, а если вы используете ReloadableResourceBundleMessageSource , вы даже можете изменить тексты без повторного развертывания приложения.

Answer 3

Я не думаю, что это плохая практика. Одна хорошая стратегия, чтобы решить, следует ли поместить некоторую логику в представление или в контроллер, состоит в том, чтобы представить сценарий, в котором у вас будет два разных движка представления . Затем вы можете проверить, не будет ли этот конкретный код повторяться в двух механизмах просмотра.

Например, допустим, у вас был тот же контроллер, но альтернативный рендер, скажем, рендерер, который генерирует электронную таблицу Excel.

В вашем примере вам придется разместить логику получения правильного сообщения не только в JSP (который отображает HTML), но также и в электронной таблице Excel (как формула).

Подводя итог, приведенный вами пример представляет логику, независимую от вида , поэтому контроллер является хорошим местом для этого.

Это не относится к логике, например, которая решает, должен ли конкретный текст отображаться жирным шрифтом или нет. Это вид конкретной логики. HTML использует таблицы для отображения жирного текста, тогда как другой движок представления использует другое представление. В этом случае лучшим местом для хранения этой логики будет слой представления (JSP для представлений HTML и т. Д.)