This chapter is going to deal with the last pattern on the SCWCD exam – The Front Controller Pattern.
What is Front Controller Pattern?
The Front Controller pattern presents one entry point to a Web site or service. It provides a centralized entry point that controls and manages Web request handling. It eliminates the dependency of the user on a direct resource. Suppose you wanted to get the latest version of the servlet specification. You would be better off going to a central page that presents options that change over time than bookmarking the servlet specification directly as your bookmark might get outdated if a new version of the specification is hosted in a different page.
This pattern is a presentation controller that allows the resources to change without breaking all the bookmarks to a given resource. Many sites use this. For example, Microsoft often changes the content in its MSDN library. However, there is front end for it that rarely changes. This way, you can bookmark that front-end URL and not worry about what they do behind it.
This is not a pattern for a data storage viewer. It isn't a way for you to control data retrieval. Rather, it is a steady interface to the underlying Web resources that behave as the presentation tier.
This pattern is like a travel agent. On every trip you start by stopping at the agency. You tell the agent where you want to go and she will take care of the arrangements. The actual flight, train, bus, and hotel details change between trips, but she always helps you get there.
When the user accesses resources directly without going through a centralized mechanism, the resource may have moved. Also, each view is on its own and required to provide its own system services. Lastly, each view has to provide navigation, but this is a problem as it doesn't know about the context or the global site.
This controller must delegate the request to the proper resource and view.
This pattern isolates the actual resources from direct access by the user.
This pattern matches the correct resource to the request.
Simplified Web sites expose all its resources directly. As a site grows, there comes a time when it is better to decouple the navigation from the resources. There needs to be a controller that manages the requests and decides which resource best satisfies the request.
• It is better to have a central controller allocate shared resources rather than have individual resources fend for themselves independently.
• The location of resources may change.
• This pattern adds only a little more work to building a Web site at first.
• Multiple resources share common needs such as security (that is, authentication and authorization).
Large Web sites especially benefit from a front controller.
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers by adding a mediator between the two, making it easier to manage changes on either side.
• Servlet Front Strategy— This pattern is implemented as a servlet, which manages the aspects of request handling that are related to business processing and control flow. Because this strategy is not specifically related to display formatting, it is a bad idea to implement this component as a JSP page.
• Command and Controller Strategy— This strategy provides a generic interface to the helper components. The controller delegates responsibility to the helper components, which minimizes the coupling among these components.
• Logical Resource Mapping Strategy— In this case users request logical names rather than physical locations. This way the physical location can be mapped to the logical names dynamically, say, in a database or XML document.
Other Related Patterns
• View Helper Pattern— The Front Controller is combined with the View Helper pattern to provide containers for factoring business logic out of the view and to provide a central point of control and dispatch. Logic is factored forward into the front controller and back into the Helpers.
• Service to Worker— The Service to Worker pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
• Dispatcher View— The Dispatcher View pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
Previous Chapter: Chapter 56 - MVC Pattern
Next chapter: Chapter 58 - Other Design Patterns
© 2013 by www.inheritingjava.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.