mvc design pattern

MVC Design Pattern

Definition

Properties

Describing MVC design patterns

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)

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.

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.

MVC

Model View Controller

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

Intent

Facilitates maintenance, extensibility, flexibility, and encapsulation by decoupling software layers from one another.

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

Architecture

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

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

View

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

Controller

– abstracts user interaction/application semantic map – translates user inputs into application actions – select appropriate data displays based on user input and context

Collaboration - Model

notifies Views when it changes application data

can be queried by the View

provides application functionality access to the Controller

Collaboration – View

presents Model data to the user

updates display when informed of data changes by the Model

forwards user input to the Controller

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)

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."

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.

Example 1 – ULM diagram

Example 2 - Dynamics

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

http://www.servlets.com/soapbox/problems-jsp.html

JSP - Model 1 Architecture

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

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

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

Model 2 Architecture

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

Tomcat Moving Parts JSP files

Completed servlets

Static documents

HTTP request HTTP response

JSP servlets

Servlet engine

Apache web server

Client

JSP EngineJSP engine

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

mail

JAF

EJB container

SessioSessionn

beansbeans

Entitybeans

Javaapplicati

on

CORBAserver

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

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

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

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

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

MVC Architecture

JSP/servlet beans

(controller)

Format beans(view)

Command beans(model)

MVC

MVC

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

Creating Dynamic Content Using Novell eDirectory™

Using eDirectory beans to dynamically create web content– Authentication– Identity management– Content management

Demonstration Sequence

JSP Pages and the useBean Tag


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();


Cooper’s Page after Authentication

• Passing input parameters to the authorization bean

get name get password ou=people, o=aspen

CreateBean—New Member Registration


Passing parameters to the CreateBean

– ObjectClass– Name– E-mail– Password

mvc design pattern

Documents