ASP.NET MVC Ile poziomów głębokości powinien mieć widok lub URL?

Question

Nadal uczę się ASP.NET MVC. W przypadku formularzy internetowych utworzyłbym nowy folder, nazwijmy go adminem. Tam mogę mieć wiele stron dla create_product, edit_product, itd. Więc URL może wyglądać jak http://somesite.com/admin/create_product.aspx.

Ale z MVC jest trochę inaczej. Próbuję zobaczyć, jaki byłby najlepszy sposób na zrobienie tego.

Czy robienie http://somesite.com/admin/product/create ma rację? A może po prostu być http://somesite.com/product/create? Jeśli robię to jako pierwszy sposób, czy umieszczam wszystko w kontrolerze "admin", czy też należy je rozdzielić na kontroler "produktu"?

Wiem, że to prawdopodobnie subiektywny lub osobisty wybór, ale chciałbym poradzić się.

Dzięki.

Answer 1

Część korzyści ASP.NET MVC (a bardziej ogólnie, mechanizm routingu URL wspólny dla wszystkich ASP.NET w .NET 3.5 SP1) jest to, że adresy URL można elastycznie skonfigurować mapować do dowolnego preferowanego folderu/pliku. Oznacza to, że modyfikowanie adresów URL po rozpoczęciu budowy jest łatwiejsze niż w czasach WebForms.

do konkretnego pytania:

• Jeden Admin kontroler vs. kontrolera Produktu - W ogóle, poradnictwo jest utrzymanie kontrolerów ukierunkowanych tak, że są one łatwiejsze do testowania i utrzymania. Z tego powodu sugerowałbym używanie pojedynczego kontrolera dla każdego typu obiektu (np. Produktu) z twoimi działaniami CRUD. Przykłady w Twoim przypadku:

  /admin/produktu/Utwórz

  /admin/product/edit/34 lub/admin/product/edit/red-shoes (jeśli nazwa jest unikalna)

  W obu przypadkach działania Create, Edit, Deatils będą w produkcie ProductController. Możesz mieć niestandardowe trasy dla "czynności administracyjnych" (takich jak Utwórz i edytuj), które ograniczają ich użycie (i dodaj tekst "admin" do adresu URL), a następnie akcja Szczegóły będzie dostępna dla wszystkich odwiedzających Twoją witrynę.

• Zabezpieczanie widoków administracyjnych - Jeden ważny fakt do zapamiętania w MVC: wszystkie żądania trafiają bezpośrednio do kontrolerów, a nie widoków. Oznacza to, że stary "bezpieczny katalog z web.config" nie stosuje się (zwykle) do MVC w celu zabezpieczenia administratora. Zamiast tego należy teraz zastosować zabezpieczenia bezpośrednio do kontrolerów. Można to łatwo osiągnąć za pomocą atrybutów do klas kontrolerów takich jak:
  • [Autoryzacja] - Po prostu sprawdza, czy użytkownik jest zalogowany w
  • [autoryzacji (Roles = „Admin”)] - Ograniczenie do określonych ról użytkowników
  • [Autoryzowanie (Użytkownicy = „Joe”)] - Ograniczenie do określonych użytkowników

można nawet utworzyć trasę niestandardową dla poglądów „admin” na swojej stronie internetowej i ograniczyć dostęp do tych widoków egzekwując Twoje sprawdzenie autoryzacji w routingu adresów URL, na przykład:

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

Gdzie AuthenticatedConstraint wyglądał:

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

Dobrych szczegółów na blogu Stephen Walther za: ASP.NET MVC Tip #30 – Create Custom Route Constraints

Answer 2

Dla rzeczy administratora, wystarczy oznaczyć atrybutem [Authorize]. Aby upewnić się, że tylko administratorzy mogą z niego korzystać, zrób coś takiego, jak [Authorize(Roles = "Admin")]. Sprawdź this question

Również/product/stworzenia jest najczęstszą, myślę :)

Answer 3

I3Dx pewno ma prawo wskazówek dla atrybutu zezwolić ma to zasadnicze znaczenie dla zachowania kontrolera bezpieczny, można zastosować do kontrolera lub indywidualne działania.

miarę głębokości URL, nie będę się martwić o głębokości, byłbym bardziej zaniepokojony, że trasa wykonana logicznego sensu na przykład:

domain.com/admin/products/edit/1

domain.com/admin/groups/edit/1

domain.com/products/view/1

domain.com/groups/view/1

ten sposób wiesz, w kapelusz dzieje się z każdą trasą. oczywiste jest, że jeden jest administratorem, a drugi użytkownikiem końcowym.

Najprostszym sposobem sprawdzenia jest sprawdzenie, czy ktoś odczytał adres URL i zapytał go, czego oczekują.

Mam nadzieję, że to pomoże.

OH i ostatnia rzecz, w przypadku tras po stronie klienta często używamy "ślimaków" zamiast identyfikatorów, aby były bardziej czytelne. Więc gdy ktoś tworzy produkt my slugify nazwę dzięki czemu może być stosowany w trasie, takich jak:

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

zamiast

domeny. com/products/view/1