10_-_MVC

emptyslowInternet and Web Development

Nov 12, 2013 (3 years and 11 months ago)

89 views

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