Explaining the FrontController pattern

In the Java EE world, we commonly work with complex projects that have similar functionalities and processes. Sometimes, using various controllers to handle a request is a bad practice because it needs to be configured at multiple endpoints and incurs a large cost of creation and maintenance. Consequently, creating a central point to treat a request is a very good solution, as it creates one point to manage all or a group of requests and then sends this request to the correct process. We can then treat all points that are common to all functionalities and send the request to a process to treat the questions that are not common to all but are specific to one functionality. Some configurations, such as session configuration, the maximum size limit of a request, cookie, and header, are common to all requests and can be configured from a central point.

The FrontController pattern is a pattern that creates a central manager to treat all requests or a request group of an application and then sends the requests to one specific process, which is generally a command. This pattern is rarely used on common projects because today we have some ready-made solutions, and implementing this pattern is generally unnecessary. This pattern is used by frameworks such as JSF, Spring MVC, and struts. The following diagram depicts this pattern:

In the preceding diagram, we have FrontController, AbstractCommand, Command1, and Command2. FrontController receives all requests, treats some common points of the request, and sends this request to the matching command. AbstractCommand is the abstract class of command. Command1 and Command2 are the subclasses of command, which implement its correspondent logic.

In our case, we will have two pages—a homepage and a login page. If the user is logged in at the moment that a request is sent, then the application will launch the login page, and then the homepage.