Problem Applications require persistence. Access mechanisms and APIs vary across different persistence technology. Components should be independent of the actual persistence mechanism.
One Solution Use the DAO pattern to isolate persistence semantics from business semantics. Business components use the DAO to access the persistence layer. This pattern could be merged with the Strategy, Builder, and Abstract Factory patterns to allow for the dynamic selection of persistence mechanisms.
Participants Business Object: Requires access to the Data Store. Data Access Object: Translates requests from the Business Object into requests against the Data Store. Data Store: Performs actual storage of the data.
Results Data access is transparent since the client code doesn't need to know the implementation details. Centralizes all data access into its own layer thus providing better application partitioning reduced client complexity.
Problem There are common processes required by all requests made to an application. Security Content retrieval There is no centralized handler for these requests. This makes each component perform these tasks in its own way which can lead to redundant code.
One Solution Use the Front Controller pattern to provide a single point of contact for all client requests. The Front Controller integrates with all other application services such as security, persistence, etc. This allows common code to be moved into the Front Controller.
Participants Front Controller: The initial point of contact for all client requests.
Results Provides centralized control since all requests funnel through the Front Controller. As common services are moved into the Front Controller, we gain improved manageability. Common services can be performed in a consistent way.
Problem To effectively create dynamic content, we often need to mix business and presentation logic. Such a combination can result in an application that is difficult to maintain. Such a combination doesn't promote the separation of roles within a project.
One Solution Requests are forwarded to a logical view. Business logic is removed from the view and factored into helper classes such as JavaBeans.
Participants View: The logical view that is ultimately responsible for generating the content presented to the client. ViewHelper: An object that encapsulates various business logic that is called on by the view to construct the dynamic content.
Results Improved role separation and application partitioning by factoring business logic from presentation logic. Since the business logic is encapsulated into a helper object that can be used elsewhere in an application, we can achieve improved reuse.
Problem Certain elements of a web-based application may be common to multiple views. If these elements are coded directly into each view, we may have maintenance and consistency issues in the future.
One Solution Use a Composite View to assemble various atomic components into the final view. Each atomic element can be re-used in other views.
Participants Composite View: The view ultimately responsible for presenting content to the client. View Manager: An object that knows how to assemble the final elements into the view.