- Presentation Tier Design Considerations
- Presentation Tier Bad Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Presentation Tier Bad Practices
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.
In this part of the book, we highlight what we consider to be bad practices in the presentation tier.
In each section, we briefly describe the bad practice and provide numerous references to design issues, refactorings, and patterns that provide further information and preferable alternatives. We do not provide an in-depth discussion of each bad practice, but rather present a brief synopsis as a starting point for further investigation.
The "Problem Summary" section provides a quick description of a less than optimal situation, while the "Solution Reference" section includes references to:
Patterns that provide information on context and trade-offs;
Design considerations that provide related details;
Refactorings that describe the journey from the less than optimal situation (bad practice) to a more optimal one, a best practice, or pattern.
Consider this part of the book as a roadmap, using the references to locate further detail and description in other parts of the book.
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
Consolidate control code, introducing a controller and associated Command helpers.
See "Introduce a Controller" on page 74.
See "Localize Disparate Logic" on page 83.
See "Front Controller – "Command and Controller Strategy" on page 179.
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.
See "View Helper" on page 186
See "Guarding a View" on page 38.
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.
See "Hide Presentation Tier-Specific Details From the Business Tier" on page 91.
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.
See "Hide Presentation Tier-Specific Details From the Business Tier" on page 91.
Allowing Duplicate Form Submissions
Problem 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.
Solution Reference
To address these issues, monitor and control the request flow.
See "Introduce Synchronizer Token" on page 77.
See "Controlling Client Access" on page 38.
See "Synchronizer (or D_ vu) Token" on page 43.
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.
Solution Reference
Protect sensitive resources, disallowing direct client access
See "Hide Resource From a Client" on page 100.
See "Controlling Client Access" on page 38.
Assuming <jsp:setProperty> Will Reset Bean Properties
Problem Summary
While the expected behavior of the <jsp:setProperty> standard tag is to copy request 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.
See "Helper Properties—Integrity and Consistency" on page 46.
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.
See "Introduce a Controller" on page 74.
See "Front Controller–"Command and Controller Strategy" on page 179.
See "Localize Disparate Logic" on page 83.
See "View Helper" on page 186.