Когда необходимо отделить условие / логику между контроллером и представлением?

Question

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

Я просто не знаю, как определить, когда вставлять контроллер, а когда не вставлять контроллер. Есть ли проблемы с производительностью?

Спасибо.

Answer 1

Наличие некоторой логики в представлении само по себе неплохо, если у вас есть роли контроллера (что делать и что показывать) и представления (как показывать) отдельно.Это помогает вам иметь понятный и понятный код.Примечание: модели - это то, где все «как делать».

Контроллер - это то, где пользователь взаимодействует с приложением и его моделями, а представление - это то, что отображается для пользователя.Эмпирическое правило: если вам нужно каким-то образом реагировать на ввод пользователя в представлении, тогда ваша логика не в том месте.

Хорошая логика представления:

<p><%= @user.name -%> <%= '(admin)' if @user.admin? -%></p>
<ul>
<% @user.documents.each do |document| %>
  <%= render "/documents/#{document.format}_list", :document => document %>
<% end %>
</ul>

Этоплохо:

<% @user = User.find params[:id] %>

Answer 2

Это не проблема производительности. Это проблема обслуживания. Например, если у вас есть логика, нелегко написать тест на логику в системе. Если он находится в контроллере, то совсем просто написать тест. Если вы видите много логики, то снова возникнет проблема с webform.

Answer 3

В терминах Rails модель выступает в качестве промежуточного уровня в многоуровневом приложении.Поместите свою логику в модели, а не в контроллеры или представления.Если представлению или контроллеру необходимо выбрать, что отображать, спросите модель, можно ли что-то сделать и реализовать функцию в модели.

<% if @model.sais_its_ok %>
  OK Go ahead
<% else %>
  Sorry, Not allowed!
<% end %>

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

Они сообщают модели о необходимости сохранения данных.Модель выполнит проверки, и если они потерпят неудачу, они сообщат контроллеру, что он не смог этого сделать, и модель даже скажет контроллеру, почему (и vuiews) в хэше ошибок.

Пожалуйста, если выс другого языка, помните, что модель является средним уровнем, контроллеры просто должны передавать данные между средним уровнем (модели и представлениями). В этом суть настоящей архитектуры MVC.

Ответ от @jimworm прекрасно демонстрирует это в своем ответе, спрашивая модель, является ли это администратором?

Answer 4

Проблема не в производительности, а в разделении интересов.Контроллер должен содержать бизнес-логику;Например, логика, используемая для определения того, какие данные нужно извлечь с учетом некоторого пользовательского ввода.

Затем контроллер передает данные в представление.Логика в представлении должна касаться только того, как отображать данные пользователю.Должны ли определенные вещи быть во множественном числе?Должны ли определенные элементы интерфейса отображаться / скрываться на основе возвращаемых данных?Логика этих вещей проста и должна входить в ответственность представления.

Исходя из вашего вопроса, кажется, у вас правильная идея, если простая логика в вашем представлении не является бизнес-логикой.

Answer 5

На самом деле я потратил некоторое время на свои сторонние проекты, выясняя, являются ли утверждения из моих шаблонов на сайте mvc (или, по крайней мере, стремящимся быть mvc), над которым я работаю.

Если вы хотите придерживаться строжайших значений mvc, то, по вашему мнению, не должно быть никаких логических конструкций. Так что даже при рендеринге набора - скажем, списка - у вас должен быть цикл foreach, который (от вашего контроллера) имеет аргументы для части шаблона и вызывает эту часть снова и снова. Что мне не нравится в этом, так это то, что это может привести к очень неэффективному коду, если вы не будете осторожны с тем, как вы агрегируете свое окончательное, составное представление, содержащее все части вашего представления. Это особенно верно, если используемая вами библиотека шаблонов имеет метод рендеринга b / c, если вы делаете это таким образом - вы, вероятно, будете вызывать «рендер» снова и снова. По сути, вам, скорее всего, придется выполнять агрегирование строк, а не строить представление одним потоком.

Итак - что я делал, так это то, что у меня есть файлы шаблонов, которые я на самом деле помечал как «контроллеры». Итак, здесь у меня будут IF / FOREACH или другие логические конструкции и вызовы соответствующих подшаблонов / подпредставлений. Я не думаю, что кто-то сказал, что ваш файл шаблона должен быть просто вид. Я думаю, что парадигма в том, что ваш ВЗГЛЯД НЕ должен иметь логических конструкций. Изоляция этих логических конструкций путем создания файлов шаблонов, которые на самом деле являются контроллерами, а не частями вашего представления, должна обеспечить счастливую среду.

Пример (с использованием библиотеки шаблонов Google Closure)

Смешение логики и представления (не очень хорошо ... но вы действительно не поймете почему, пока не построите сложное представление таким образом):

/**
 *
 * Template description
 *
 * @param paramA description of paramA 
 * @param paramB description of paramB
 * @param paramC description of paramC
 *
 *
 */
{template .myTemplate}
     <div class="{$paramA}">
       {if $paramC}
         <span class="{$paramB}">Some content</span>
       {/if}
     </div>
{/template}

Разделение логики и вида. Обратите внимание, что файл шаблона контроллера ничего не добавляет к представлению. Он просто вызывает другой шаблон.

Файл шаблона контроллера:

/**
 *
 * Template description
 *
 * @param condition description of condition
 * @param parameters parameters to call subtemplate with
 *
 */
{template .myTemplate}
     {if $condition}
          {call .getTemplForCondition data="$parameters" /}
     {else}
          {call .getTempl data="$parameters" /}
     {/if}
{/template}

А потом файл шаблона ... теперь без логики ...

/**
 *
 * Template description
 *
 * @param paramA description of paramA 
 * @param paramB description of paramB
 *
 */
{template .getTemplForCondition}
     <div class="{$paramA}">
         <span class="{$paramB}">Some content</span>
     </div>
{/template}

/**
 *
 * Template description
 *
 * @param paramA description of paramA 
 *
 */
{template .myTemplate}
     <div class="{$paramA}"></div>
{/template}