Блог

Я все еще разбираюсь в MVC и стараюсь оставаться максимально верным шаблону. У меня есть модель со свойством Status, среди прочих. Контроллер вызывает представление и передает соответствующую модель. В представлении, если статус = «Неполный», мне нужно, чтобы он отображался Incomplete <a href="blah">Complete registration</a> , если статус = «В списке ожидания», мне нужно, чтобы он отображался On Waiting List: Position @Model.WaitListPosition и т.д. и т.п.

Логика для принятия решения о том, что показывать на основе статуса, будет в представлении, поскольку оно определяет, как оно представлено пользователю, верно? Или строка должна быть встроена в контроллер и передана в представление?

Первый вариант лучше. Контроллер должен быть как можно более тонким. Пусть представление решает, как отображать переданные ему данные.

Не создавайте строку в контроллере, если только вы не хотите, чтобы ваша бизнес-логика находилась в контроллере, а не в ваших бизнес-компонентах. Если вы абсолютно чувствуете необходимость представить это в виде строки, поскольку это единственный способ решить эту проблему, попросите бизнес-компонент выполнить фактическую работу.

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

Эта логика лучше всего подходит для вашего представления — в конечном итоге это сводится к повторному использованию кода, и это специфично для конкретного представления. Если вам нужно одинаковое поведение в нескольких представлениях, все равно было бы лучше, чтобы эта логика выполнялась в представлении либо как частичное представление, либо как пользовательский HTML-помощник. Сохраняйте логику в своих контроллерах как можно более краткой.

Разделение задач диктует, что контроллер не должен знать о том, как вы отображаете данные, только вызов model, необходимый для извлечения данных, необходимых для представления, который будет включать поле Status . Представление применяется везде, где логика должна диктовать, как преобразовать данные для отображения.

Некоторые фреймворки (Ruby on Rails — единственная, которую я знаю) предоставляют способы извлечения логики преобразования данных из макета представления. В случае RoR они называются помощниками. Например, у вас был бы вызван этот вспомогательный метод, format_status который принимает статус в качестве своего параметра и возвращает ожидаемый HTML-рендеринг. Обратите внимание, что это позволяет вам легко писать модульные тесты для этого метода без необходимости иметь дело с (более) сложными тестами веб-просмотра.