In a moment we will discuss the Struts approach to the MVC
controller and then provide detail on the building-block classes,
first we should take a step back and look at the nail for which Struts
is attempting to be the hammer. In many web applications, the basic
HTTP interaction is not especially complicated. An HTTP request
includes at least the name of a resource and zero or more parameters.
Based on the name of the resource and the parameters, control must be
handed off to specialized code that performs an action. The action
determines what response is appropriate; this HTTP response is then
encoded and returned to the requester, typically with HTML as the
message body. So far, so good.
But in ad hoc web programming, it is all too easy to handle each of these tasks in an idiosyncratic way. For example, a developer might write a servlet to handle a request and might create his own methods and conventions for validating parameters (ensuring that certain parameters are syntactically valid phone numbers, perhaps). Meanwhile, another coder, working primarily on GET requests, writes her own method for validating parameters. Clearly, there are organizational and maintenance issues here with the existence of two modules doing similar tasks, maintained by two different people. But the larger issue is that there are well-known patterns for handling such minutiae—and if handled once, and well, ...