[DSBW Spring 2009] Unit 07: WebApp Design Patterns & Frameworks (1/3)
1. Unit 7: Design Patterns and Frameworks
Web presentation layer patterns
The Model-View-Controller (MVC) architectural pattern
Catalog of MVC-based patterns
Other patterns
Web presentation-business integration patterns
Business layer architectural patterns
MVC Web frameworks
dsbw 2008/2009 2q 1
2. The MVC Architectural Pattern
Divides an interactive application into three components/levels:
Model, View and Controller
Model:
Contains the functional core of the application
Encapsulates the appropriate data, and exports procedures that
perform application-specific processing
View:
Displays information to the user
Obtains the data from the model
Different views present the information of the model in different ways
Controller:
Accepts user input as events
Translates events to service requests for the model or display requests
for the view
dsbw 2008/2009 2q 2
3. The “Classical” MVC Pattern
Observer
*
update()
1
Model
data
attach( ob : Observer )
View
Controller
detach( ob : Observer )
notify() 1 1
initialize( m : Model )
getData() initialize( m : Model, v : View )
makeController()
service() handleEvent()
activate()
update()
display()
update()
dsbw 2008/2009 2q 3
4. Catalog of MVC-Based Web Presentation Patterns
Controller Patterns:
Page Controller
Front Controller
Application Controller
Intercepting Filter
View Patterns
View Helper
Composite View
Transform View
Composite Patterns:
Dispatcher View
Service to Worker
dsbw 2008/2009 2q 4
5. Page Controller
Each Page Controller component act as the controller for a dynamic
page on the Web site.
The basic responsibilities of a Page Controller are:
Decode the URL and extract any form data
Invoke model components to process the request data
Determine which view should display the result page and forward the
model information to it
dsbw 2008/2009 2q 5
7. Page Controller: When to Use It
Page Controller works particularly well in a site where most of the controller
logic is pretty simple:
: System
: User
service(parameters)
result
Variant: Page Controller and View implemented by the same Server Page:
(Model 1)
dsbw 2008/2009 2q 7
8. Front Controller (Model 2)
Problem: The system requires a centralized access point for
request handling. Without a central access point, control code that
is common across multiple requests is duplicated in numerous
places. When control code is intermingled with view-creation code,
the application is less modular and cohesive.
Forces:
You want to avoid duplicate control logic.
You want to apply common logic to multiple requests.
You want to separate system processing logic from the view.
You want to centralize controlled access points into your system
Solution: Use a Front Controller as the initial point of contact for
handling all related requests. The Front Controller centralizes
control logic that might otherwise be duplicated, and manages the
key request handling activities .
dsbw 2008/2009 2q 8
11. Front Controller + Application Controller
An Application Controller has two main responsibilities: deciding which
domain logic to run and deciding the view with which display the response.
It is useful for designing complex use cases with definite rules about the
order in which pages should be visited and different views depending on
the state of objects.
Separating the Application Controller from the Front Controller allows
improving the modularity of the system, while enhancing its reusability.
The Application Controller component is not a Server Page
dsbw 2008/2009 2q 11
13. Application Controller with Mapper
Application Controller: Uses Mapper to resolve an incoming request
to the appropriate action and view, to which it delegates or dispatches.
Mapper: Uses a Map to translate an incoming request into the
appropriate action and view. A Mapper acts as a factory
Map: Acts as a dictionary or registry of references to target resources.
Target: A resource that helps fulfill a particular request (view,
command)
dsbw 2008/2009 2q 13
16. Intercepting Filter
Problem: You want to intercept and manipulate a request and a response
before and after the request is processed in order to determine if:
The client has a valid session
The request path violates any constraint
You support the browser type of the client
The client has used a special encoding to send the data
The request stream is encrypted or compressed
Forces
You want centralized, common processing across requests
You want pre and postprocessing components loosely coupled with core
request-handling services.
You want pre and postprocessing components independent of each other and
self contained to facilitate reuse.
Solution: Use an Intercepting Filter as a pluggable filter to pre and
postprocess requests and responses. A Filter Manager combines loosely
coupled filters in a chain, delegating control to the appropriate filter.
dsbw 2008/2009 2q 16
17. Intercepting Filter: Structure, Participants and Responsibilities
FilterManager: Manages filter processing. It creates the FilterChain with
the appropriate filters, in the correct order, and initiates processing.
FilterChain: Ordered collection of independent filters
Filter: Component that performs a specific pre and/or postprocessing task.
Target: The resource requested by the client.
dsbw 2008/2009 2q 17
19. Java Filters: Example
Motivation: HTML forms that include a file upload use a different
encoding type than that of basic forms. As a result, form data that
accompanies the upload is not available via simple getParameter()
invocations. The following filter preprocesses requests to translate
the encoding type into a single consistent format that makes all form
data available as request attributes:
public class MultipartEncodeFilter extends javax.servlet.Filter {
public void doFilter(javax.servlet.ServletRequest request,
javax.servlet.ServletResponse response,
javax.servlet.FilterChain filterChain)
throws java.io.IOException, javax.servlet.ServletException {
String contentType = request.getContentType();
if (contentType.startsWith(quot;multipart/form-dataquot;) ) {
For each pair (attributeName, value) obtained from the request
do request.setAttribute(attributeName, value)
}
filterChain.doFilter(request, response); }
}
dsbw 2008/2009 2q 19
20. View Helper
Problem: You want to separate a view from its processing logic.
JSP and other template-based views allow embedding scriptlet code
Embedded scriptlet code cannot be reused easily
Embedded scriptlet code often acts as control code or performs view preparation
activities, such as content retrieval.
Mingling control logic, data access logic and formatting logic leads to problems
with modularity, reuse, maintenance, and role separation.
Forces:
You want to use template-based views, such as JSP.
You want to avoid embedding program logic in the view.
You want to separate programming logic from the view to facilitate division of
labor between software developers and web page designers
Solution: Use Views to encapsulate formatting code and Helpers to
encapsulate view-processing logic.
A View delegates its processing responsibilities to its helper classes,
implemented as POJOs, custom tags, or tag files.
Helpers serve as adapters between the view and the model, and perform
processing related to formatting logic, such as generating an HTML table.
dsbw 2008/2009 2q 20
21. View Helper: Structure
Helper: Encapsulates processing logic for generating and
formatting a View. A helper typically adapts a PresentationModel for
a view or provides access to the raw data of the PresentationModel
PresentationModel: Holds the data retrieved from the business
service, used to generate the View. It can be either a Business
Delegate or a DTO
dsbw 2008/2009 2q 21
23. View Helper: Example with JavaBean and JSTL
<%@ taglib uri=http://java.sun.com/jsp/jstl/core prefix=quot;cquot; %>
<jsp:useBean id=quot;welcomeHelperquot; scope=quot;requestquot;
class=quot;WelcomeHelperquot; />
<HTML>
<BODY bgcolor=quot;FFFFFFquot;>
<c:if test = quot;${welcomeHelper.nameExists == true}quot;>
<center><H3> Welcome
<b><c:out value='${welcomeHelper.name}'/> </b><br><br></H3>
</center>
</c:if>
<H4><center>We are happy for your visit!</center></H4>
</BODY></HTML>
dsbw 2008/2009 2q 23
24. Composite View
Problem: You want to build a view from modular, atomic
component parts that are combined to create a composite whole,
while managing the content and the layout independently.
Forces
You want common subviews, such as headers, footers and tables
reused in multiple views, which may appear in different locations within
each page layout.
You have content in subviews that frequently changes or might be
subject to certain access controls, such as limiting access to users in
certain roles.
You want to avoid directly embedding and duplicating subviews in
multiple views which makes layout changes difficult to manage and
maintain.
Solution: Use Composite Views that are composed of multiple
atomic subviews. Each subview of the overall template can be
included dynamically in the whole, and the layout of the page can
be managed independently of the content.
dsbw 2008/2009 2q 24
25. Composite View: Structure
Template: Represents the page layout
ViewManager: Uses a Template to enforce a layout into which it places the
appropriate content.
A simple ViewManager might use the standard JSP include tag (<jsp:include>)
to include SimpleView segments into a Template.
A more sophisticated ViewManager might use POJOs or custom tag helpers to
provide content and layout management in a more comprehensive and robust
manner.
dsbw 2008/2009 2q 25
27. Transform View
Problem: You want a view that processes domain data element by
element and transforms it into HTML.
Forces: The data returned by the business layer is either in XML or
in something automatically transformable to it
Solution: Use a Transform View that transforms directly from
domain-oriented XML into (X)HTML by using XSLT (eXtensible
Stylesheet LanguageTransformations). Normally XSLT does this by
transforming each XML element into an (X)HTML element.
dsbw 2008/2009 2q 27
28. Dispatcher View
Problem: You want a view to handle a request and generate a
response, with little or no business processing performed before
rendering the view.
Forces:
You have static views
You have views generated from an existing presentation model
You have views which are independent of any business service
response
You have limited business processing
Solution: Use Dispatcher View with views as the initial access point
for a request. Business processing, if necessary in limited form, is
managed by the views.
dsbw 2008/2009 2q 28
29. Dispatcher View: Structure
BusinessHelper: Helps the View initiate business processing to handle a
request
BusinessService: Encapsulates the business logic and business state. A
remote business service is accessed via a Business Delegate
PresentationModel: Holds the data retrieved from the business service
(DTO).
dsbw 2008/2009 2q 29
31. Service To Worker
Problem: You want to perform core request handling and invoke
business logic before control is passed to the view
Forces:
You want specific business logic executed to service a request
in order to retrieve content that will be used to generate a
dynamic response.
You have view selections which may depend on responses from
business service invocations.
You may have to use a framework or library in the application
Solution: Use Service to Worker to centralize control and request
handling to retrieve a presentation model before turning control over
to the view. The view generates a dynamic response based on the
presentation model.
dsbw 2008/2009 2q 31