Java Reference
In-Depth Information
It is evident that the JSP controller in Listing 3-2 tries to perform three main tasks:
1.
Intercept the incoming request.
2.
Invoke the Enterprise JavaBeans components to carry out the business operation
in several
if-else
blocks.
3.
Finally, select the next view to display and bind the model object returned by the
invocation of business methods.
This resembles the MVC architectural pattern discussed earlier. However, the JSP
controller component takes on too many responsibilities, thus deviating from the
single
responsibility principle
(SRP). SRP states that every class should have one and only one
responsibility, and all its functions should be tightly aligned to this responsibility.
Adherence to a single concern makes the class robust, and it has limited chances of
modification. SRP is explained in greater detail at
http://c2.com/cgi/
wiki?SingleResponsibilityPrinciple
.
You should also consider whether JSP is the appropriate technology to be used as a
controller. This is because every technology in the Java EE platform has its own role. JSP
was intended to be a dynamic view technology. This allowed the user interface code to be
written by developers who were expert in HTML and JavaScript with some knowledge of
JSP tags, scriptlets, and implicit objects. These developers need not be seasoned Java pro-
grammers, freeing up the latter to focus on writing business and data access logic. Hence,
it is recommended that you use JSP as a dynamic view technology and not as a controller.
Forces
• Too many controllers make it difficult to maintain and reuse.
• There should be a single point of entry into the entire application.
• The controller should follow SRP. It should intercept requests and delegate busi-
ness logic invocation and view selection to pluggable components.
• JSPs should not be used as controllers.
• Extend functionality declaratively around the single entry point.
