Model
-
View
-
Controller
Architectural Style
Outline:
MVC Pattern
MVC in J2EE
J2ME (Thursday)
MVC: Problems with GUI programs
•
User interfaces are especially prone to changes
in requirements
–
New types of input
•
Keyboard
•
Mouse
•
Pen
•
Remote
–
New types of output
•
Porting to different “look
-
and
-
feel”
•
Information visualization: charts, graphs, plots
•
Output device heterogeneity: PDAs, applets, Javascript,
HTML, Swing
MVC: Problems with GUI programs
•
New features require user
-
interface
changes
–
User must have a way to access the feature
–
ex. Add in
-
text spellcheck to word processor
MVC: Changes Required for
SpellCheck Feature
•
Changes to input: Need to input
corrections and update the underlying
document model
•
Changes to underlying document model:
None
MVC Example: Simple
Spreadsheet System
•
Consider a simple spreadsheet system for
entering data and viewing charts
•
Without major impact to the system, it
should be possible to:
–
Add a new non
-
interactive view of the data
–
Add a new interactive view of the data
MVC Example: Simple
Spreadsheet System
Model
-
View
-
Controller Style
•
Divides interactive application into three types of
components
–
Model: Contains core functionality and data
–
View: Displays information to the user
–
Controller: Handles user input
•
Goals: Separation of concerns
–
Reuse
–
Organizes code structure
–
Independent development
•
Change propagation (implicit invocation)
mechanism ensures consistency between user
interface and model
–
Works differently in J2EE
MVC Behavior
•
Controllers receive events from
manipulation of interface
–
May or may not be integrated with View
•
Translate event into operations on the
Model
•
Each View registers itself with the Model
through implicit invocation
•
When the Model changes all Views are
automatically updated consistently
MVC Pattern
Original J2EE Architecture (Model 1)
•
Web browser directly accesses JSP pages
–
No MVC architecture
•
Each JSP page processes its own inputs
–
Manages cookies, sessions, request
parameters
•
JSP includes logic to choose next page to
return
×
Hard to modify application flow
MVC in J2EE (Model 2)
•
Introduces a controller between the
browser and the JSP pages
•
Controllers centralize the logic for
dispatching requests to the next view
•
Controllers handle view selection, which
decouples JSP pages from one another
•
View accesses the Model directly
–
No implicit invocation
–
Recall HTTP limitations
MVC Summary in J2EE
•
The Web
-
tier controller receives each incoming HTTP request
•
Invokes the requested operations on the application model
•
Based on the results of the operation and state of the model, the
controller then selects the next view to display
•
Finally, the controller generates the selected view and transmits it to
the client for presentation
Model 2 Design
•
Coupling vs. Cohesion
–
One giant Controller for entire web site
–
One controller for each possible event
•
Each controller should handle relatively independent
state machines (
page flow
)
–
Logging in
–
Registering
–
Playing a game
–
Administration
•
Enables reusable
web modules
–
Controllers, associated Views, and model Beans
–
Loosely coupled, resusable application parts
–
Not explicitly part of the Spring Framework
•
Decouples controllers from irrelevant model elements
Spring MultiActionController
•
Enables each controller to export several methods
•
Methods are dispatched by Spring Framework
•
Simplifies controller logic enabling more modular design
import org.springframework.web.servlet.mvc.multiaction.MultiActionController;
public class TicketController extends MultiActionController {
public ModelAndView reserve(HttpServletRequest req, HttpServletResponse res)
{
//perform logic to reserve a ticket based on the request coming in
}
public ModelAndView cancel(HttpServletRequest req, HttpServletResponse res)
{
//perform logic to cancel a reservation based on the request coming in
}
}
Spring MultiActionController
Configuration
•
Specify the MultiActionController for your controller class
–
Set the methodNameResolver property
<bean id="paramMultiController“ class=“TicketController">
<property name="methodNameResolver">
<ref bean="paramResolver"/>
</property>
</bean>
•
Create a ParameterMethodNameResolver referred to by controller
–
Set the paraName property to the URL parameter specifying method to call
–
ex. http://localhost:8080/springapp/login?method=newUser
<bean id="paramResolver"
class="org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameResolve
r">
<property name="paramName">
<value>method</value>
</property>
</bean>
Controlling
Page Flow
•
Controllers implement page flow
•
JSPs do not refer to one another
•
Controller dynamically chooses the "next"
page
•
Next view (page) to display depends on:
–
Results of any operation on the application
model
–
Session state
–
URL and Request parameters
–
Form input
Login Controller Example
•
Next view to display after a sign on very
likely depends on:
–
The user id and password contained in the
request
–
The success or failure of the sign on
operation
–
Other server
-
side state
•
maximum number of allowed users
•
the URL the user was trying to access
Templating
•
Many web applications present multiple
Views on a single web page
–
Need to keep consistent layout
–
Keep views consistent with model updates
–
Avoid using frames
–
Enables modular decomposition
Templating Example
Templating Steps
1. Create a ModelEnvironment Bean
2. Insert all “model beans” into the
ModelEnvironment using bean configuration
3. Create a PageChooser Bean
4. Create a Template JSP
5. Use PageChooser and ModelEnvironment in
Controllers
6. Use PageChooser and ModelEnvironment in
JSPs
Templating: ModelEnvironment
Bean
•
Model environment bean will store all the model
elements
•
Allows multiple views to have access to different model
elements
class ModelEnvironment
{
private Map model;
//Getters and Setters
}
Templating: Bean Configuration
•
Use Bean configuration to put all model beans in the model environment
•
Use qualified names to separate namespaces for web modules
–
This is good design but not enforced by the framework
<beans>
<!
-
Bean definitions for userInfo and gameState
--
>
<!
-
Hookup beans to Controllers
--
>
<bean id=“modelEnvironment” class=“ModelEnvironment”>
<property name=“model”>
<map>
<key name=“
login.userInfo
”>
<ref bean=“userInfo”/>
</key>
<key name=“
game.gameState
”>
<ref bean=“gameState”/>
</key>
</map>
</property>
</bean>
</beans>
Templating: PageChooserBean
•
Allows controller to change multiple views
public class PageChooserBean
{
private String banner;
private String navigationMenu;
private String body;
private String footer;
//Getters and Setters
}
Templating: Template JSP
Example Template Page
<html>
<head><title>SpringApp</title></head>
<body>
<table>
<tr>
<td>
<jsp:include page=“${model.chooser.banner}”/>
</td>
</tr>
<tr>
<td>
<jsp:include page=“${model.chooser.navigationBar”/>
</td>
<td>
<jsp:include page=“${model.chooser.body”/>
</td>
</tr>
<tr>
<td>
<jsp:include page=“${model.chooser.footer}”/>
</td>
</tr>
</table>
</body>
</html>
Templating: Template JSP
•
Use “include” tag to dynamically choose JSP
page
•
Recall ${name} is used by JSP to retrieve
variables from a Map type passed in by
controller
•
Included JSP pages can refer to model variables
in their namespace
–
ex. ${model.login.userInfo}
–
“model” is name given by controller
–
“login” is web module name
–
“userInfo” is bean name given in bean configuration
Templating: Controller use
•
Controllers will have reference to model environment and page chooser bean
•
Controllers can set multiple views by changing the page chooser bean
•
Controllers will return template JSP and model environment for each request
import org.springframework.web.servlet.mvc.multiaction.MultiActionController;
public class TicketController extends MultiActionController {
private Map globalModelMap;
private TemplateBean pageChooserBean;
public ModelAndView reserve(HttpServletRequest req, HttpServletResponse res) {
//Main controller code
templateBean.setBanner(“reservationBanner”);
templateBean.setBody(“reservationAccepted”);
return new ModelAndView(“template”,”model”,globalModelMap);
}
public ModelAndView cancel(HttpServletRequest req, HttpServletResponse res) {
//perform logic to cancel a reservation based on the request coming in
}
//Getters and Setters
}
Templating: Web Module Design
•
Accessing the model from Controller
–
Hookup model beans to Controllers using configuration
–
Do not access the ModelEnvironment directly from controllers
(ModelEnvironment is for JSPs)
•
Why?
–
Connections between controllers and model components are clear in
configuration and controller code
–
Connections are statically typed
»
No casts are necessary
•
What if a JSP from one module,
A
, needs to refer to a
bean from another module,
B
?
–
Do not access the other module namespace directly in JSP
–
Hookup the bean from module B to a bean in module A
•
Access the required bean through the bean in module A
•
Why?
–
Connections between modules are clear in configuration
–
Connections between modules should not be hidden in JSPs
Conclusion: MVC and J2EE
•
MVC Architectural Style
–
Good separation of concerns
–
Divides interactive application into three types of
components
–
Updates are propagated through implicit invocation
•
Model 1 and Model 2 Architecture
–
J2EE does not use implicit invocation
•
Page flow and Controller decomposition
•
MultiActionController
•
Web site templating
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Comments 0
Log in to post a comment