MVC Design Pattern

 Definition

 Properties

 Describing MVC design patterns

Page 1
 Patterns

“Each pattern describes a problem which occurs over and over again in
our environment, and then describes the core of the solution to that
problem, in such a way that you can use this solution a million times
over, without ever doing it the same way twice”
– Christopher Alexander
(building architect)

Page 2
 Object Technology
Patterns
 A pattern is a named description of a problem and solution
that can be applied in new contexts.
 Patterns codify the principles and idioms that guide
experienced developers in their creation of software.
 What is and isn’t a pattern depends on your point of view.

Page 3
 Object Technology
Patterns 2
 Design patterns are not about structures such as vectors that can be
encoded in classes and reused as is, nor are they complex domain
specific designs.
 Ideally, patterns should include guidance for how they can be applied in
novel situations.
 Many patterns provide guidance for how responsibilities should be
assigned to objects.

Page 4
 MVC

 Model View Controller

 Increases reusability by partially decoupling data
presentation, data representation, and application
operations. Enables multiple simultaneous data views.

Page 5
 Intent

 Facilitates maintenance, extensibility, flexibility, and

encapsulation by decoupling software layers from one
another.

Page 6
 Advantages

 The Model-View-Controller ("MVC") design pattern

separates the application data from both the ways the data
can be viewed or accessed,
 and from the mapping between system events (including
user interface events) and application behaviors

Page 7
 Architecture

Page 8
 Applicability

 Use Model View Controller:

– for distributed applications
– for larger applications
– for applications with a long lifetime
– to enhance interface and back-end portability
– where identical data must be viewed and manipulated in multiple ways.
– to improve maintainability
– to support concurrent, modular development with many developers
– to facilitate division of labor by skill set
– to facilitate unit testing
– with enterprise beans that are reusable across applications

Page 9
 Model

– abstracts application functionality

– encapsulates the application state
– provides access to application functions
– manages persistence, when there is persistence
– notifies interested parties when data change

Page 10
 View

– abstracts data presentation

– presents data to the user
– maintains consistency with model data

Page 11
 Controller

– abstracts user interaction/application semantic map

– translates user inputs into application actions
– select appropriate data displays based on user input and context

Page 12
 Collaboration - Model

 notifies Views when it changes application data

 can be queried by the View
 provides application functionality access to the Controller

Page 13
 Collaboration – View

 presents Model data to the user

 updates display when informed of data changes by the
Model
 forwards user input to the Controller

Page 14
 Collaboration - Controller

 translates user inputs into application actions on the Model

 selects the View to present based on user input and Model
action outcome(s)

Page 15
 Consequences

 Clarifies design by separating data modeling issues from data display and user interaction.
 Allows the same data to be viewed in multiple ways.
 Allows the same data to be viewed by multiple users.
 Improves extensibility by simplifying impact analysis.
 Improves maintainability by encapsulating application functions behind well-known APIs, and decreasing code
replication ("copy-paste-and-hack").
 Enhances reusability by decoupling application functionality from presentation.
 Makes applications easier to distribute, since MVC boundaries are natural distribution interface points.
 Can be used to partition deployment and enable incremental updates.
 Facilitates testability by forcing clear designation of responsibilities and functional consistency.
 Enhances flexibility, because data model, user interaction, and data display can be made "pluggable."

Page 16
 Implementation - Issues

 Since components can't take advantage of knowledge of other components'

implementation details, performance must be balanced with the other considerations
above. Skillful API design can overcome this pitfall to some extent.
 MVC may not scale well in distributed systems, if communication volume and latency
issues are not carefully addressed.
 MVC applications can be difficult to maintain if the Model's API is in flux, since the
Controller is written in terms of the Model API. Implementing Controller/Model
communication as a Command pattern can minimize API drift and provide a hook for
Controller extensions to handle new Model functions. Alternately, in many cases it's
possible to use an Adapter to provide backward API compatibility.

Page 17
 Example 1 – ULM
diagram

Page 18
 Example 2 - Dynamics

Page 19
 The Problem with
Servlets
 From http://www.servlets.com/soapbox/problems-jsp.html

 HTML content has to be created within code

 Content creators have to ask developers to make all content
changes

Page 20
 JSP - Model 1
Architecture

Page 21
 Strengths of Model 1

 Very easy to implement

 initially requires "no brainer" knowledge of JSP and Java
 http://www.brainopolis.com/jsp/mvc/KDuffey_MVC.html;jsessionid=PAKAIKKBNABA

Page 22
 Problems with Model 1

 Having web designers and developers working on the same

file isn't ideal.
 Java inside HTML proves almost as awkward as having
HTML inside Java

Page 23
 Model 2 explanation

 requests are submitted to a servlet "controller" that

performs business logic and generates an appropriate data
"model" to be displayed
 This data is then passed internally to a JSP page "view" for
rendering
 The appropriate JSP page can be selected to do the display

Page 24
 Model 2 Architecture

Page 25
 Advantages of Model 2

 takes advantage of the predominant strengths of both

technologies, using JSP to generate the presentation layer
and servlets to perform process-intensive tasks
 the more complex your application, the greater the benefits
of using the Model 2 architecture should be

Page 26
 Tomcat Moving Parts
JSP files

JSP engine
Engine
JSP servlets Completed servlets

Static documents

Servlet engine

Apache web server

HTTP request HTTP response

Client
Page 28
 Tomcat and JBOSS =
J2EE
(X)HTML HTTP(S) Tomcat web container JDBC RDBMS
XML Servlets JSPs
Tag
Mail
library JavaMail server
RMI / IIOP

Java mail
JNDI Java

JDBC
JTA

JAF
Applet RMI application

JMS
CORBA
IIOP server
EJB container
Client
application Session Entity
beans beans
JNDI
eDirectory™
Java mail
RMI / IIOP

JDBC
JNDI

JTA

JAF
JMS

JMS
Message queue
Page 29
 A Tomcat Application
Tomcat
WebApps
examples
Web application images
JSP
JSP
JSP Meta-inf
Servlet
Servlet
Servlet servlets
Servlet
Web-inf

JSP compiler Web.xml

Classes
Lib
Page 30
 Tomcat in Stand-Alone
Mode
 When a servlet container is stand-
alone, it acts as its own web
server
– It completely bypasses the
traditional HTTP server Servlet
Container
Servlet
 When running in stand-alone JVM
mode, special requests are Servlet
generally forwarded to port 8080

Page 31
 In-Process Container

Web Java
server plug-in Servlet
JVM
Servlet

 The in-process container configuration requires the servlet container to be bound

to the web server by a plug-in that is responsible for mediating communication
between the server and the container

 The plug-in and the container run in the server’s memory space, as does the JVM
that executes the servlet and its container

Page 32
 Out-of Process Servlet
•
Container
This configuration option involves utilization of two memory spaces
• The first supports the web server and the Java plug-in
• The other supports the JVM and the servlet container

Web Java
server plug-in Servlet Container
JVM
Servlet Servlet

Page 33
 MVC Architecture
Model View Controller
Model Data View
(Bean properties)
Beans JSPs
Event Event
(request) (forward)
Display info
Data <jsp:getProperty>
Controller Action URLs
Event

Servlets (request)
Browser

Page 34
 MVC Architecture
JSP/servlet beans
(controller)

MVC

Command beans Format beans

(model) (view)
Page 35
 Command Beans
 Java bean that encapsulates a single business logic task
 Provides a stable boundary between the business logic and
user interface
 Allows business logic to evolve without disrupting the rest of
the web application
 Can be serialized and distributed

Page 36
 Creating Dynamic
Content

Using Novell eDirectory™
Using eDirectory beans to Demonstration Sequence
dynamically create web
content
– Authentication
– Identity management
– Content management

Page 37
 JSP Pages and the
useBean Tag
Demonstration Sequence

Page 38
 Authorization Bean
Demonstration Sequence
<jsp:useBean id= "authBean"
class="com.novell.ecb.ldap.AuthenticateLdap" scope="request" />
// Call the execute method command bean
authBean.execute();

• Chris Cooper is already

a registered member
who has specific
interests
• His identity is kept in
the directory along with
specialized attributes
that are extensions of
his user object

Page 39
 Cooper’s Page after
Authentication

• Passing input parameters to

the authorization bean
get name
get password
ou=people, o=aspen

Page 40
 CreateBean—New
Member Registration
Demonstration Sequence

 Passing parameters to the

CreateBean
– ObjectClass
– Name
– E-mail
– Password

Page 41
Page 42