ASP.NET MVC Сколько уровней должно быть в представлении или URL?

Question

Я все еще изучаю ASP.NET MVC. С помощью веб-форм я бы создал новую папку, назовем ее admin. Там у меня может быть много страниц для create_product, edit_product и т. Д. Так что URL может выглядеть как http://somesite.com/admin/create_product.aspx.

Но с MVC все немного по-другому. Я пытаюсь понять, что будет лучшим способом сделать это.

Будет ли правильно http://somesite.com/admin/product/create? Или это должно быть просто http://somesite.com/product/create? Если я делаю это в качестве первого способа, я помещаю все в контроллер «admin» или его следует разделить на контроллер «product»?

Я знаю, что это, вероятно, субъективный или личный выбор, но я хотел бы получить совет.

Спасибо.

Answer 1

Преимущество ASP.NET MVC (и, в более общем смысле, механизма маршрутизации URL-адресов, общего для всех ASP.NET в .NET 3.5 SP1), заключается в том, что URL-адреса можно гибко настраивать для сопоставления с любой структурой папок / файлов Вы предпочитаете. Это означает, что гораздо проще, чем в те дни, когда WebForms изменяли ваши URL, после того как вы начали строить свой проект.

К вашим конкретным вопросам:

• Один контроллер администратора по сравнению с контроллером продукта - В целом, руководство должно быть сосредоточено на контроллерах, чтобы их было проще тестировать и обслуживать. По этой причине я бы предложил использовать один контроллер для каждого типа объекта (например, Product) с вашими действиями CRUD. Примеры в вашем случае:

  / администратор / продукт / создать

  / admin / product / edit / 34 или / admin / product / edit / red-shoes (, если имя уникально)

  В любом случае действия Create, Edit, Deatils будут все в ProductController. У вас могут быть только собственные маршруты для «действий администратора» (например, «Создать и изменить»), ограничивающие их использование (и добавление текста «администратор» в URL), и тогда действие «Детали» будет доступно всем посетителям вашего сайта.

• Защита представлений администратора - Один важный факт, который следует помнить с помощью MVC: все запросы направляются непосредственно в контроллеры, а не в представления. Это означает, что старый «безопасный каталог с web.config» не применяется (обычно) к MVC для защиты вашего администратора. Вместо этого вы должны применить безопасность непосредственно к контроллерам. Этого легко достичь, используя атрибуты для классов контроллера, такие как:
  • [Авторизовать] - просто проверяет, вошел ли пользователь в систему
  • [Authorize (Roles = "Admin")] - ограничение для определенных ролей пользователя
  • [Authorize (Users = "Joe")] - Ограничение для определенных пользователей

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

routes.MapRoute(
  "Admin",
  "Admin/{controller}/{action}",
  new { controller = "Product", action = "Index" },
  new { authenticated= new AuthenticatedConstraint()}
);

Где AuthenticatedConstraint выглядит примерно так:

using System.Web;
using System.Web.Routing;
public class AuthenticatedConstraint : IRouteConstraint
{
  public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection)
  {
    return httpContext.Request.IsAuthenticated;
  }
}

Хорошие подробности в блоге Стивена Вальтера: ASP.NET MVC Совет № 30 - создание пользовательских ограничений маршрута

Answer 2

I3Dx определенно имеет правильное руководство для атрибута Authorize, это важно для обеспечения безопасности контроллера, вы можете применить к контроллеру или к отдельным действиям.

Что касается глубины URL, я бы не беспокоился о глубине, меня больше беспокоит, что маршрут имеет логический смысл, например:

domain.com / админ / продукты / редактировать / 1

domain.com / администратор / группы / редактировать / 1

domain.com / продукты / вид / 1

domain.com / группы / просмотр / 1

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

Самый простой способ проверить это - заставить кого-то прочитать ваш URL и спросить его, что они ожидают увидеть.

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

И, наконец, для клиентских маршрутов мы часто используем "слизни", а не идентификаторы, чтобы сделать их более читабельными. Поэтому, когда кто-то создает продукт, мы добавляем название, чтобы его можно было использовать в маршруте, например:

domain.com / продукты / вида / большое красное ведро

вместо

domain.com / продукты / вид / 1

Answer 3

Для админки просто пометьте атрибутом [Authorize]. Чтобы убедиться, что только администраторы могут использовать его, сделайте что-то вроде [Authorize(Roles = "Admin")]. Проверьте этот вопрос

Кроме того, / product / create является наиболее распространенным, я думаю:)