The application controller pattern
Some web applications have a complex logic for defining the correct view, content, or action to invoke. The MVC controller can be used to make this decision and get the correct view, content, or action. However, sometimes the logic to define a decision is very hard, and using the MVC controller to do this can cause duplication of a lot of code. To solve this, we need to centralize the logic at one point to permit an easy maintenance and a central logic point.
The application controller pattern is the pattern that permits the centralization of all view logic and promotes a unique process to define the flow of pages. This pattern is used together with FrontController, discussed earlier, and is an intermediary between FrontController and Command. Using this pattern, we will promote the decoupling between view treatment and request treatment. The following diagram represents this:
In the preceding diagram, we can see the ApplicationController between FrontController and AbstractController. When the client sends a request, the FrontController receives this and treats points about the request. The FrontController then sends this request to ApplicationController, which treats points about the view and flow and defines the correct Command to execute.
In our example scenario, we want to create one point to download a file on our server, and this point can only be accessed by a logged-in user. As well as this, we will only accept PDF downloads and JPG files. In this example, we will create one class called DownloadFrontController to receive the request. We will also create a class called DownloadApplicationController to process the logic of view and content choice. AbstractCommand is the abstract class for commands. In addition to this, we will create PdfCommand, which is an implementation of AbstractCommand that processes the logic to download one PDF file. Finally, we will create JpgCommand, which is an implementation of AbstractCommand that processes the logic to download one JPG file.