10_-_MVC

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