sobota, 15 maja 2010

Debugowanie ścieżek ASP.NET MVC: Routes Debugger step by step

errorroad Routing ASP.NET MVC może zrobić sporo zamieszania, jeśli w naszej aplikacji korzystamy z zaawansowanego sterowania pomiędzy kontrolerami i odpowiadającymi im widokami. Dla dużych aplikacji (w obecnej chwili pracuję nad taką, która posiada ponad 120 kontrolerów – i nie ma tu problemów z refaktoryzacją) odpowiednie pokierowanie przepływem żądań to całkiem skomplikowany problem.

Są dwie metody debugowania ścieżek:

  1. Metoda empiryczna, czyli zmieniamy tabelę ścieżek, klikamy F5, po czym zamykamy oczy.
  2. Za pomocą biblioteki RoutesDebug – i tą metodę opiszę za chwilę.

RoutesDebug, czyli

RoutesDebug to pojedyńcza bilblioteka dostępna za darmo, która po dołączeniu do naszej aplikacji MVC oraz odpowiednim skonfigurowaniu (co jest dziecinnie proste) stanie się domyślnym RouteHandlerem.

Czyli zaczynamy

1. Pobieramy bibliotekę RoutesDebug.dll

2. W Visual Studio dodajemy referencję do niej w naszej aplikacji ASP.NET MVC

add_ref

3. Czas na rejestrację naszego nowego RouteHandlera. Przechodzimy do pliku Global.asax.cs i dodajemy jedną (!) linijkę:

protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();

RegisterRoutes(RouteTable.Routes);

//Powstań RoutesDebugerze:
RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);

}

To wszystko. Teraz po uruchomieniu aplikacji powinniśmy ujrzeć stronę na, której prezentowana jest tablica ścieżek w naszej aplikacji.

routesdebug1

Tak naprawdę to jest to nasza konsola testowa :-) Ok, dla przykładu stworzyłem bardzo prostą aplikacyjkę, która zawiera następujące rejestracje scieżek:


public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(null, "Articles/{id}",
new { controller = "Articles", action = "Show" },
new { id = @"\d{1,9}" }
);

routes.MapRoute(null, "Articles/Show/{id}",
new { controller = "Articles", action = "Show" },
new { id = @"\d{1,9}" }
);

routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
);

}

Do kontrolera Articles będziemy dopuszczać jedynie ścieżki które spełniają następujące wymagania:

  • Zawierają numer artykułu, który za pomocą prostego wyrażenia regularnego testowany jest, czy jest liczbą
  • Jeśli nie podamy nazwy metody, to przyjmujemy, że chodzi o metodę Show

Natomiast w konsoli testowej widzimy, że dla wywołania ścieżki: http://localhost/Articles/Show/1 pasujące są wpisy w tablicy:

  • Articles/Show{id}
  • {controller}/{action}/{id}

gdzie jako parametr przekazujemy nasz ID, czyli tutaj liczbę 1, kontroler to ArticlesController, a akcja to Show. Ale w naszym przykładzie zarejestrowałem także scieżkę, w której podanie nazwy akcji jest opcjonalne, przetestujmy więc ją:

http://localhost/Articles/1234

routesdebug3

czyli ścieżka także została rozpoznana, a pusta nazwa akcji została automatycznie uzupełniona przez wywołanie akcji Show, zgodnie z tym co podaliśmy w naszej tablicy routingu. Pozostał ostatni test, czyli test na niepoprawne dane, wpisujemy http://localhsot/Articles/darek –> to nie jest liczba :-)

routesdebug4

ścieżki nie zostały dopasowane, czyli wszystko działa.

2 komentarze:

dario-g pisze...

http://flux88.com/blog/fluent-route-testing-in-asp-net-mvc/ :)

Dariusz Tarczyński pisze...

@dario-g
Dzięki za linka, bardzo ciekawe.