Upload
tonylane
View
922
Download
1
Embed Size (px)
DESCRIPTION
It is about the MVC Design Pattern
Citation preview
Page 1
MVC Design Pattern
Definition
Properties
Describing MVC design patterns
Page 2
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 3
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 4
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 5
MVC
Model View Controller
Increases reusability by partially decoupling data presentation, data representation, and application operations. Enables multiple simultaneous data views.
Page 6
Intent
Facilitates maintenance, extensibility, flexibility, and encapsulation by decoupling software layers from one another.
Page 7
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 8
Architecture
Page 9
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 10
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 11
View
– abstracts data presentation – presents data to the user – maintains consistency with model data
Page 12
Controller
– abstracts user interaction/application semantic map – translates user inputs into application actions – select appropriate data displays based on user input and context
Page 13
Collaboration - Model
notifies Views when it changes application data
can be queried by the View
provides application functionality access to the Controller
Page 14
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 15
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 16
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 17
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 18
Example 1 – ULM diagram
Page 19
Example 2 - Dynamics
Page 20
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 21
JSP - Model 1 Architecture
Page 22
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 23
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 24
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 25
Model 2 Architecture
Page 26
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 28
Tomcat Moving Parts JSP files
Completed servlets
Static documents
HTTP request HTTP response
JSP servlets
Servlet engine
Apache web server
Client
JSP EngineJSP engine
Page 29
Tomcat and JBOSS = J2EE
(X)HTMLXM
L
ApplAppletet
Clientapplication
HTTP(S)
RDBMS
Mailserver
JDBC
JavaMail
RMI
IIOP
eDirectory™
JNDI
Message queue
JMS
Servlets Tag
library
RM
I /
IIO
PJN
DI
JTA
JDB
C
JMS
Java
mail JAF
Tomcat web containerJSP
s
RM
I /
IIO
P
JND
I
JTA
JDB
C
JMS
Java
JAF
EJB container
SessioSessionn
beansbeans
Entitybeans
Javaapplicati
on
CORBAserver
Page 30
A Tomcat ApplicationTomcat
WebApps
examples
images
JSP
servlets
Meta-inf
Web-inf
Web.xml
Classes
ServletServletServletServletServletServletServletServletServletServletServletServletServletServletServletServlet
JSPJSPJSPJSPJSPJSPJSPJSP
JSP compilerJSP compilerJSP compilerJSP compiler
Lib
Web applicationWeb application
Page 31
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
When running in stand-alone mode, special requests are generally forwarded to port 8080
Servlet Container Servlet
ServletJVM
Page 32
In-Process Container
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
Web
server
Java
plug-in
Servlet
JVMServlet
Page 33
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
JVM
Web
server
Java
plug-in
ServletServlet
Servlet Container
Page 34
MVC Architecture
Data(Bean properties)
Event
(request) Display info
Data <jsp:getProperty>Action URLs
Model View Controller
Model
Beans
View
JSPs
Controller
Servlets
Event
(forward)
Event
(request) Brows
er
Page 35
MVC Architecture
JSP/servlet beans
(controller)
Format beans(view)
Command beans(model)
MVC
MVC
Page 36
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 37
Creating Dynamic Content Using Novell eDirectory™
Using eDirectory beans to dynamically create web content– Authentication– Identity management– Content management
Demonstration Sequence
Page 38
JSP Pages and the useBean Tag
Demonstration Sequence
Page 39
Authorization Bean
• 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
<jsp:useBean id= "authBean" class="com.novell.ecb.ldap.AuthenticateLdap" scope="request" />// Call the execute method command
bean
authBean.execute();
Demonstration Sequence
Page 40
Cooper’s Page after Authentication
• Passing input parameters to the authorization bean
get name get password ou=people, o=aspen
Page 41
CreateBean—New Member Registration
Demonstration Sequence
Passing parameters to the CreateBean
– ObjectClass– Name– E-mail– Password
Page 42