ASP.NET MVC Quanti livelli profondi dovrebbe avere una vista o un URL?

Question

Sto ancora imparando ASP.NET MVC. Con webforms, vorrei creare una nuova cartella, chiamiamola admin. Lì potrei avere molte pagine per create_product, edit_product, ecc. Quindi l'URL potrebbe apparire come http://somesite.com/admin/create_product.aspx.

Ma con MVC è un po 'diverso. Sto cercando di vedere quale sarebbe il modo migliore per farlo.

Farebbe http://somesite.com/admin/product/create ha ragione? O dovrebbe essere solo http://somesite.com/product/create? Se lo faccio come prima cosa, metto tutto nel controller "admin" o dovrei essere separato in un controller "prodotto"?

So che questa è probabilmente una scelta soggettiva o personale, ma mi piacerebbe avere qualche consiglio.

Grazie.

Answer 1

Parte del vantaggio di ASP.NET MVC (e più in generale, il motore di routing URL comune a tutti ASP.NET in .NET 3.5 SP1) è che gli URL possono essere configurati in modo flessibile per mappare a qualsiasi cartella/struttura di file che preferisci. Ciò significa che è molto più facile di quanto non fosse ai tempi di WebForms per modificare i tuoi URL dopo aver iniziato a costruire il tuo progetto.

alle vostre domande specifiche:

• un controller Admin vs. CONTROLLER - In generale, la guida è quello di mantenere i controller focalizzati in modo che siano più facili da testare e mantenere. Per questo motivo, suggerirei di utilizzare un singolo controller per tipo di oggetto (come Product) con le azioni CRUD. Esempi nel tuo caso:

  /admin/prodotto/creare

  /admin/prodotto/modificare/34 o/admin/prodotto/modificare/rosso-calzature (se nome è univoco)

  In entrambi i casi, le azioni Create, Edit, Deatils si troveranno tutte nel ProductController. Potresti avere percorsi personalizzati per le "azioni di amministrazione" (come Crea e Modifica) che limitano il loro utilizzo (e aggiungi il testo "admin" all'URL), e quindi l'azione Dettagli sarebbe utilizzabile da tutti i visitatori del tuo sito.

• Protezione delle viste dell'amministratore - Un dato importante da ricordare con MVC: tutte le richieste vanno direttamente ai controller, non alle viste. Ciò significa che la vecchia "sicurezza di una directory con web.config" non si applica (di solito) a MVC per proteggere il tuo amministratore. Invece, dovresti ora applicare la sicurezza direttamente ai controller. Questo può essere facilmente ottenuto utilizzando attributi a classi controller come:
  • [Autorizza] - Basta verifica che l'utente è connesso in
  • [Autorizza (ruoli = "Admin")] - Limitato a ruoli utente specifici
  • [Autorizza (utenti = "Joe")] - Limitato a utenti specifici

È anche possibile creare un percorso personalizzato per la vista "admin" nel tuo sito e limitare l'accesso a quelle viste di far rispettare la tua autorizzazione controlla il routing degli URL, come questo:

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

Dove AuthenticatedConstraint sembra qualcosa di simile:

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

Buone dettagli sul blog di Stephen Walther: ASP.NET MVC Tip #30 – Create Custom Route Constraints

Answer 2

Per materiale amministrativo, è sufficiente contrassegnare con l'attributo [Authorize]. Per assicurarti che solo gli amministratori possano utilizzarlo, fai qualcosa come [Authorize(Roles = "Admin")]. Controlla per this question

Inoltre,/prodotto/creare è più comune, credo :)

Answer 3

I3Dx ha sicuramente la giusta guida per l'attributo Autorizza, questo è essenziale per mantenere regolatore di sicuro, è possibile applicare a un controller o singole azioni.

Per quanto riguarda la profondità URL, io non mi preoccuperei della profondità, sarei più preoccupato del fatto che il percorso aveva un senso logico, ad esempio:

domain.com/admin/products/edit/1

domain.com/admin/groups/edit/1

domain.com/products/view/1

domain.com/groups/view/1

questo modo si sa w cappello sta accadendo con ogni percorso. è ovvio che uno è un amministratore e uno è un utente finale.

Il modo più semplice per controllare è convincere qualcuno a leggere l'URL e chiedere loro cosa si aspettano di vedere.

Spero che questo aiuti.

OH e un'ultima cosa, per le rotte lato client spesso usiamo "slug" piuttosto che id in modo che sia più leggibile. Così, quando qualcuno crea un prodotto che slugify il nome in modo che possa essere utilizzato nel percorso come ad esempio:

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

piuttosto che

dominio. it/products/view/1