Centralizacja zarządzania widokami (elementami warstwy view) aplikacji webowej w pojedynczym obiekcie przyjmującym żądania klientów.

Wiele interakcyjnych aplikacji internetowych ma strukturę zbioru osobnych stron powiązanych nawzajem ze sobą. Takie aplikacje są trudne do utrzymania i modyfikacji:

• Kiedy strona zostaje przeniesiona, wszystkie odwołania (linki) do strony muszą zostać zmodyfikowane.

• Kiedy część stron wymaga zabezpieczenia dostępu hasłem, różne pliki konfiguracyjne muszą być zmieniane, dla każdej strony osobno.

• Kiedy stronie jest przypisywany nowy wygląd (nowa warstwa widoku), niezbędna jest modyfikacja zawartości strony.

Powyższe problemy mogą być rozwiązane poprzez skierowanie wszystkich żądań klientów do jednego obiektu, zwanego front controller. Funkcje takie jak wybór widoku, autoryzacja, itp mogą być scentralizowane w obrębie kontrolera, który przekazuje żądania do odpowiednich elementów systemu. Dzięki temu, jeśli potrzebna jest zmiana zachowania określonych funkcji, tylko mała część aplikacji musi być modyfikowana: front controller.

Wzorzec Front Controller powinien być stosowany dla:

• aplikacji webowych ze skomplikowaną nawigacją dynamicznie generowanych stron.

• aplikacji webowych wymagających autoryzacji, polityk, transformacji itp.

Wzorzec projektowy Front Controller ma następujące zalety:

• Nawigacja jest czytelniejsza i łatwiejsza w konfiguracji. Wybór widoku odbywa się w obrębie kontrolera, więc wystarczy przeanalizować kod kontrolera, żeby zrozumieć nawigację wewnątrz całej aplikacji. Podobnie, wystarczy jedynie zmodyfikować kontroler, w celu zmiany nawigacji pomiędzy stronami.

• Widoki są zarządzane w spójny sposób. Front controller otrzymuje wszystkie żądania od klientów, więc może w konsystentny sposób zastosować niezbędne transformacje oraz polityki bezpieczeństwa dla wszystkich widoków. Łatwiej jest także skonfigurować zachowanie poszczególnych funkcji, ponieważ wystarczy zmodyfikować tylko kontrolera.

• Widoki mogą być łatwo zmieniane. Widoki komunikują się tylko z kontrolerem, więc nie ma żadnych zależności pomiędzy poszczególnymi widokami. Dzięki temu, widoki mogą być łatwo podmieniane i wykorzystywane wielokrotnie dla różnych stron.

Wzorzec ma również pewne konsekwencje, które mogą być zarówno pozytywne jak i negatywne:

• Złożoność aplikacji jest przeniesiona do front controllera. Uproszczenie interakcji pomiędzy poszczególnymi widokami odbywa się kosztem zwiększenia złożoności kontrolera. W konsekwencji, jeśli aplikacja się rozwija, utrzymanie i modyfikacje kontrolera stają się coraz trudniejsze.

Front controller zazwyczaj jest implementowany jako servlet, a nie jako strona JSP, ponieważ służy do kontroli obiegu sterowania. Nie należy natomiast do warstwy widoku.

W celu skierowania wszystkich żądań klientów do kontrolera, należy przydzielić obiekt kontrolera do obsługi wszystkich URLi danej aplikacji. Służy do tego element servlet-mapping w konfiguracji XMLowej serwera. Oto przykład:

<web-app>
  <!-- ... -->

  <servlet>
    <servlet-name>webTierEntryPoint</servlet-name>
    <!-- ... -->

    <servlet-class><!-- MainServlet --></servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>webTierEntryPoint</servlet-name>
    <url-pattern>/control/*</url-pattern>
  </servlet-mapping>
  <!-- ... -->

</web-app>

Następnie należy dodać logikę do kontrolera, przetwarzającą nadchodzące żądania, stosującą odpowiednie transformacje zgodne z polityką serwera, wywołującą niezbędne funkcje aplikacji i zwracającą odpowiedni widok jako odpowiedź.

Następujące kwestie powinny być rozważone przy stosowaniu wzorca Front Controller:

• Wirtualne nazwy URL. Według tej strategii, adresy linków (URLe), powinny odzwierciedlać logiczną zawartość stron, a nie fizyczna lokalizację. Dzięki temu są czytelniejsze dla użytkowników oraz developerów serwisu. Nazwy nie powinny być tworzone na podstawie technicznej zawartości stron. Na przykład należy stosować nazwę index, a nie index.html, czy index.jsp.

• Kontroler nie powinien przyjmować żądań dostępu do stron z zawartością statyczną. Kontroler powinien być stosowany do zarządzania nawigacją stron generowanych dynamicznie. Ze względów wydajnościowych, dla stron statycznych lepiej jest stosować dostęp bezpośredni, z pominięciem kontrolera.