MVC - Условия в представлениях

Question

Цитирование из примера приложения NerdDinner ASP.NET MVC

    <%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<%
    if (Request.IsAuthenticated) {
%>
        Welcome <b><%= Html.Encode(Page.User.Identity.Name) %></b>!
        [ <%= Html.ActionLink("Log Off", "LogOff", "Account") %> ]
<%
    }
    else {
%> 
        [ <%= Html.ActionLink("Log On", "LogOn", "Account") %> ]
<%
    }
%>

Это частичное представление usercontrol с именем LoginStatus.ascx. Как вы можете видеть, существует условие, которое изменяет «весь» вывод представления. Это правильный путь. Было бы лучше, если бы был контроллер, оценивающий это состояние и затем отображающий соответствующий частичный вид?

И независимо от вашего ответа на предыдущий вопрос, как я могу использовать последний подход в ASP.NET MVC, т. Е. Может ли родительское представление вызвать контроллер (вместо выполнения RenderPartial для UserControl) и позволить ему решить, какое частичное представление сделать?

Answer 1

Как насчет этого подхода:

Раствор 1 :

Создайте метод расширения в HtmlHelper, который будет отображать представление «WelcomeMessage.Anonymous.aspx» или «WelcomeMessage.Authenticated.aspx» на основе запроса.

<%= Html.LoginStatus() =>

И поместить эти представления в / Views / Shared

/Views/Shared/LoginStatus.Anonymous.ascx
/Views/Shared/LoginStatus.Authenticated.ascx

Решение 2 :

Просто замените if / else операторы на элемент управления ASP.NET * LoginView в вашем LoginStatus.ascx

<asp:LoginView Runat="Server">
    <LoggiedInTemplate>
        Welcome, <%= Html.Encode(Model.UserName) %>!
        <button>Sign Out</button>
    </LoggedInTemplate>
    <AnonymousTemplate>
        <button>Sign In</button> | <button>Join Now!</button>
    </AnonymousTemplate>
</asp:LoginView>

См. Также :

• Советы и рекомендации по ASP.NET MVC

Answer 2

Я думаю, что если представление собирается измениться в соответствии с каким-то условием, то оно должно обеспечить выполнение представления. Но если условие меняется не по внешнему виду (т. Е. «Отрицательные числа должны быть красными»), а по поведению (т. Е. «Если пользователь вошел в систему, он / она должен увидеть кнопку ВХОД, а не кнопку ВХОД»), то его контроллер должен решить , Вы можете ввести уровень «рендерера» между контроллером и страницей.

Answer 3

Вместо того, чтобы решить, аутентифицирован ли пользователь в представлении, вы можете сделать это в контроллере, например так:

public ActionResult ShowAPage()
{
   if(!HttpContext.User.Identity.IsAuthenticated) 
   {
      return RedirectToRoute("ShowLoginPage")
   }
   return View();
}

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

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

Вот один из способов сделать это без использования фильтра действий, но вы можете сделать все виды способов, один хороший способ - создать собственный контроллер, который наследуется от контроллера и переопределяет методы View для выбора соответствующей главной страницы. 1008 *

public ActionResult ShowAPage()
{
   if(!HttpContext.User.Identity.IsAuthenticated) 
   {
      return View("ShowAPageView", "LoggedInMasterPageName");
   }
   return View("ShowAPageView", "LoggedOutMasterPageName");    
}

Надеюсь, это поможет.

Answer 4

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

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

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

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

Не беспокойся, ты все делаешь правильно.