ASP.NET MVC Combien de niveaux doit être une vue ou une URL?

Question

J'apprends toujours ASP.NET MVC. Avec les formulaires Web, je créer un nouveau dossier appelons-le admin. Là, je pourrais avoir beaucoup de pages pour create_product, edit_product, etc. Donc l'URL pourrait ressembler à http://somesite.com/admin/create_product.aspx.

Mais avec MVC c'est un peu différent. J'essaie de voir quelle serait la meilleure façon de le faire.

Le fait de faire http://somesite.com/admin/product/create aurait-il raison? Ou devrait-il être juste http://somesite.com/product/create? Si je le fais en premier, dois-je tout mettre dans le contrôleur "admin" ou doit-il être séparé en un contrôleur "produit"? Je sais que c'est probablement un choix personnel ou subjectif, mais je voudrais obtenir quelques conseils.

Merci.

Answer 1

L'avantage d'ASP.NET MVC (et plus généralement, le moteur de routage d'URL commun à tous les ASP.NET dans .NET 3.5 SP1) est que les URL peuvent être configurées de manière flexible pour mapper à n'importe quelle structure de dossier/fichier que vous préférez. Cela signifie qu'il est beaucoup plus facile qu'au moment de WebForms de modifier vos URL après avoir commencé à construire votre projet.

à vos questions spécifiques:

• Un contrôleur d'administration par rapport à contrôleur produit - En général, la direction est de garder les contrôleurs concentrés afin qu'ils soient plus faciles à tester et à entretenir. Pour cette raison, je suggère d'utiliser un seul contrôleur par type d'objet (comme le produit) avec vos actions CRUD. Exemples dans votre cas:

  /admin/produit/créer

  /admin/produit/modifier/34 ou/admin/produit/modifier/rouge-chaussures (si le nom est unique)

  Dans les deux cas, les actions Create, Edit, Deatils seront toutes dans le ProductController. Vous pouvez avoir des routes personnalisées pour les "actions d'administration" (comme Créer et modifier) ​​qui limitent leur utilisation (et ajouter le texte "admin" à l'URL), puis l'action Détails sera utilisable par tous les visiteurs de votre site.

• Sécurisation des vues Admin - Un fait important à retenir avec MVC: toutes les demandes vont directement aux contrôleurs, pas aux vues. Cela signifie que l'ancien "sécuriser un répertoire avec web.config" ne s'applique pas (généralement) à MVC pour sécuriser votre Admin. Au lieu de cela, vous devez maintenant appliquer la sécurité directement aux contrôleurs. Cela peut facilement être réalisé en utilisant des attributs aux classes Controller comme:
  • [Authorize] - vérifie simplement que l'utilisateur est
  connecté
  • [Authorize (rôles = « Admin »)] - Limiter aux rôles spécifiques des utilisateurs
  • [Authorize (utilisateurs = « Joe »)] - limiter aux utilisateurs spécifiques

Vous pouvez même créer un itinéraire personnalisé pour les vues « admin » dans votre site et l'accès limite à ces vues par l'application votre contrôle d'autorisation dans le routage d'URL, comme ceci:

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

Où AuthenticatedConstraint ressemble:

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; 
    } 
} 

bons détails sur le blog de Stephen Walther: ASP.NET MVC Tip #30 – Create Custom Route Constraints

Answer 2

Pour les tâches d'administration, marquez simplement l'attribut [Authorize]. Pour vous assurer que seuls les administrateurs peuvent l'utiliser, faites quelque chose comme [Authorize(Roles = "Admin")]. Commander this question

En outre,/produit/créer est le plus courant, je pense :)

Answer 3

I3Dx a certainement la bonne orientation de l'attribut Autorisez, ce qui est essentiel pour maintenir le contrôleur sécurisé, vous pouvez demander à un contrôleur ou des actions individuelles.

En ce qui concerne la profondeur d'URL, je ne vous inquiétez de la profondeur, je serais plus préoccupé que la route était logique par exemple:

domain.com/admin/products/edit/1

domain.com/admin/groups/edit/1

domain.com/products/view/1

domain.com/groups/view/1

De cette façon, vous savez w Il se passe un chapeau avec chaque route. il est évident que l'un est un administrateur et l'autre est un utilisateur final. Le moyen le plus simple de vérifier est de demander à quelqu'un de lire votre URL et de lui demander ce qu'il s'attend à voir.

Espérons que cela aide.

OH et une dernière chose, pour les routes côté client, nous utilisons souvent des "slugs" plutôt que des ids, de sorte qu'il est plus lisible. Alors, quand quelqu'un crée un produit que nous slugify le nom afin qu'il puisse être utilisé dans la route tels que:

domain.com/products/view/big-red-bucket

plutôt que

domaine. com/products/view/1