!FrAgile Thinking

Główna zaletą a jednocześnie wadą frameworków udostępnionych przez Microsoft jest to, że ich domyślna konfiguracja pozwala na bezproblemowe rozpoczęcie z nimi przygody. Prowadzi to do tego, że aplikacje oparte o te frameworki, wdrożone na środowisku produkcyjnym często korzystają z zbędnych funkcjonalności. Tak też jest z ASP.NET MVC.

Plik web.config nowo stworzonego projektu ASP.NET MVC posiada w większości przypadków niepotrzebne rejestracje modułów i handlerów, pozwalających przykładowo na korzystanie z ASP.NET Ajax. Ponieważ poznając każdą nową technologię staram się “przegryźć” prze jej wnętrze, pierwszym z moich kroków w przypadku ASP.NET MVC było przejrzenie kodu, który jest odpowiedzialnie za podstawową realizację zapytania. Po krótkiej analizy wywnioskowałem, że jedynym elementem, który jest rzeczywiście wymagany w pliku web.config do uruchomienia aplikacji ASP.NET MVC jest moduł System.Web.Routing.UrlRoutingModule. Dlatego w zależności od trybu puli aplikacji, na której hostowana jest nasza aplikacja, wymagane jest pozostawienie następujących wpisów w pliku web.config:

- w przypadku managed pipeline mode: Integrated (dostępny od wersji 7.0 usługi IIS)

<configuration>
	<system.webServer>
		...
    <modules runAllManagedModulesForAllRequests="true">
			<remove name="UrlRoutingModule"/>
			<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
		</modules>
	</system.webServer>
</configuration>

- w przypadku managed pipeline mode: Classic

<configuration>
	<system.web>
    ...
		<httpModules>
			<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
		</httpModules>
	</system.web>
</configuration>

Więcej na temat możliwości i różnic wyżej przedstawionych trybów puli aplikacji można znaleźć tutaj.

Wszystko super, ale po co nam ten UrlRoutingModule?
Aby to zrozumieć należy zapoznać się  z zasadą działania wzorca Front Controller, który został zastosowany w ASP.NET MVC. Front Controller jest wzorcem często stosowany w aplikacjach webowy. W jego odpowiedzialności leży obsługiwanie wszystkich zapytań przychodzących do aplikacji i wywoływania komend(operacji) odpowiadającym tym zapytaniom.

Działanie wzorca Front Controller

źródło: http://i.msdn.microsoft.com/ms978723.Des_FrontController_Fig02(en-us,MSDN.10).gif

Powyższy diagram przedstawia standardowy scenariusz obsługiwania zapytania przy pomocy Front Controllera .
Klient wysyła zapytanie, które jest obsługiwane przez Handler. Handler dokonuje operacji wspólnych do wszystkich zapytań a następnie na podstawie adresu URL decyduje, którą z dostępnych komend(Command) wywołać. Komenda ta z kolei odpowiedzialna jest za wywołanie określonej logiki biznesowej i za przekierowanie do odpowiedniego widoku(View). Ten zaś na podstawie informacji przekazanych przez komendę, generuje stronę, która następnie zwracana jest do klienta.

Interesującym nas elementem w powyższym diagramie jest Handler, którego funkcjonalność w ASP.NET MVC częściowo realizowane jest właśnie przez UrlRoutingModule.

UrlRoutingModule odpowiedzialny jest za znalezienie obiektu typu RouteData, który przechowuje informacje o trasie odpowiadającej adresowi URL obsługiwanego zapytania. Trasa to nic innego jak szablon adresu URL, w którym można zdefiniować parametry. Na podstawie tych parametrów możliwe jest wyszukiwanie potrzebnych nam informacji z adresu URL obsługiwanego zapytania odpowiadającego wybranej trasie. Możliwe trasy są domyślnie definiowane w trakcie startu aplikacji, poprzez dodawanie ich do kolekcji RouteCollection w pliku global.asax. Ta kolekcja wykorzystywana jest właśnie przez UrlRoutingModule w celu wcześniej wspomnianego wyszukiwania trasy. Następnie wykorzystując  znaleziony obiekt RouteData (dokładniej mówiąc obiekt implementujący interfejs  IRoutingModule udostępniony przez RouteData), moduł UrlRoutingModule uzyskuje dostęp do obiektu implementującego interfejs IHttpHandler odpowiedzialnego za dalszą realizację zapytania.

W przypadku ASP.NET MVC jest to najczęściej obiekt klasy MvcHandler. Ta klasa realizuje pozostałe funkcjonalności Handlera w wzorcu Front Controller. Wywołuje ona odpowiednią komendę, wykorzystując do tego informacje udostępnione przez obiekt klasy RequestContext, który jest wstrzykiwany do obiektu MvcHandlera w trakcie jego konstrukcji. RequestContext posiada obiekt RouteData, który jak już wspominałem daje dostęp do informacji związanych z trasą. Jednym z najbardziej kluczowych informacji w tym przypadku jest parametr controller. Służy on do wyznaczenie klasy posiadającej komendę, która zostanie wykonana w celu zakończenia realizacji zapytania. To tłumaczy domyślną postać wzorców adresów URL przy rejestrowaniu tras w global.asax.

routes.MapRoute(

“Default”, // Route name

“{controller}/{action}/{id}”, // URL with parameters

new { controller = “Home”, action = “Index”, id = “” } // Parameter defaults

);

Jako, że najlepiej chyba do każdego z nas przemawia obraz a nie treść czytana, dołaczam poniżej diagram sekwencji. Diagram ten przedstawia wcześniej wspomnianą interakcję klas wykorzystywanych przez UrlRoutingModule. Pomija on jedynie aspekt związany z wybraniem odpowiedniej komendy przez klasę MvcHandler, dlatego, że jest to temat warty całego postu .

Diagram sekwencji przedstawiający zachowanie realizowane przez UrlRoutingModule