Presentation Tier Bad Practices J2EE

Bad practices are less than optimal solutions that conflict with many of the patterns' recommendations. When we documented the patterns and best practices, we naturally discarded those practices that were less than optimal.

Control Code in Multiple Views

Problem Summary

Custom tag helpers may be included at the top of a JSP View to perform access control and other types of checks. If a large number of views include similar helper references, maintaining this code becomes difficult, since changes must be made in multiple places.

Solution Reference

When there is a need to include similar control code in multiple places, such as when only a portion of a JSP View is to be restricted from a particular user,delegate the work to a reusable helper class.

Exposing Presentation-Tier Data Structures to Business Tier

Problem Summary

Presentation-tier data structures,such as HttpServletRequest,should be confined to the presentation tier. Sharing these details with the business tier,or any other tier,increases coupling between these tiers,dramatically reducing the reusability of the available services. If the method signature in the business service accepts a parameter of type HttpServletRequest,then any other clients to this service(even those outside of the Web space) must wrap their request state in an HttpServletRequest object. Additionally,in this case the business-tier services need to understand how to interact with these presentation tier-specific data structures,increasing the complexity of the business-tier code and increasing the coupling between the tiers.

Solution Reference
Instead of sharing data structures specific to the presentation tier with the business tier,copy the relevant state into more generic data structures and share those. Alternatively,extract and share the relevant state from the presentation tier-specific data structure as individual parameters.

Exposing Presentation-Tier Data Structures to Domain Objects

Problem Summary

Sharing request handling data structures, such as HttpServletRequest, with domain objects needlessly increases the coupling between these two distinct aspects of the application. Domain objects should be reusable components, and if their implementation relies on protocol or tier-specific details,their potential for reuse is reduced. Furthermore,maintaining and debugging tightly coupled applications is more difficult.

Solution Reference
Instead of passing an HttpServletRequest object as a parameter,copy the state from the request object into a more generic data structure and share this object with the domain object. Alternatively,extract the relevant state from the HttpServletRequest object and provide each piece of state as an individual parameter to the domain object.

Allowing Duplicate Form SubmissionsProblem Summary
One of the limitations of the browser-client environment is the lack of control an application has over client navigation. A user might submit an order form that results in a transaction that debits a credit card account and initiates shipment of a product to a residence. If after receiving the confirmation page, the user clicks the Back button, then the same form could be resubmitted.

Exposing Sensitive Resources to Direct Client Access

Problem Summary

Security is one of the most important issues in enterprise environments. If there is no need for a client to have direct access to certain information,then this information must be protected. If specific configuration files, property files,JSPs,and class files are not secured appropriately,then clients may inadvertently or maliciously retrieve sensitive information.

Assuming <jsp:setProperty> Will Reset Bean PropertiesProblem Summary

While the expected behavior of the <jsp:setProperty> standard tag is to copyrequest parameter values into JavaBean helper properties of the same name,its behavior when dealing with parameters that have empty values is often confusing.

For example,a parameter with an empty value is ignored, although many developers incorrectly assume that the matching JavaBean property will be assigned a null or empty string value.

Solution Reference
Take into account the less than intuitive nature of how properties are set when using the <jsp:setProperty> tag,and initialize bean properties before use.

Creating Fat Controllers

Problem Summary

Control code that is duplicated in multiple JSP views should, in many cases, be refactored into a controller. If too much code is added to a controller,though,it becomes too heavyweight and cumbersome to maintain,test,and debug. For example,unit testing a servlet controller, particularly a “fat controller,” is more complicated than unit testing individual helper classes that are independent of the HTTP protocol.

Solution Reference

A controller is typically the initial contact point for handling a request, but it should also be a delegation point,working in coordination with other control classes.

Command objects are used to encapsulate control code to which the controller delegates. It is much easier to unit test these JavaBean command objects,independent of the servlet engine,than it is to test less modular code.