Designing Web Applications. client server architectures design patterns model 2 web applications.
-
Upload
ava-bentley -
Category
Documents
-
view
219 -
download
1
Transcript of Designing Web Applications. client server architectures design patterns model 2 web applications.
Designing Web Applications
Designing Web Applications
• client server architectures
• design patterns
• model 2 web applications
client-server systems
• network of machines, each designated as a client or server
• not exclusive to intranet systems– but large web sites now the main examples– account here is web and eCommerce-biased
• different levels of complexity exist– related to more sophisticated functionality
• peer-to-peer network– any machine has client and server roles
client-server systems
• client– active (master)– sends requests– awaits response
• server– passive (slave)– waits for requests– serves requests and sends a response
thin client vs fat client
• thin client– function is mainly presentational
• e.g. standard browser functionality
– all significant processing done by server– client-server communication is frequent
• fat client– significant processing on client– e.g. Java applet, Flash, JavaScript– less communication required, less server load
2-tier client-server architecture
• client (browser)– http request– mainly for presentation of information– serving mainly static (D)HTML pages
• server (simple web server)– http response– web-server processing http– perhaps SSI, simple CGI– earliest and low-end web-sites
3-tier client-server architecture
• 3rd tier is a database layer– data persists beyond request and response
• server layer– expanded functionality
• database connectivity• user authentication and sessions• perhaps multi-threading
• client layer (web browser)– forms interface to interact with data
a typical 3-tier architecture
database/file system
webserver
andprograms
webbrowser
presentation tier logic tier data tier
multi-tier architecture• additional business logic layer(s)• middleware
– preprocessing and error handling– sophisticated transaction management
• multiple middle-ware servers– server farms linking to database layer
• web layer– standard web server
• JSP/Servelets | ASP.NET | ColdFusion |PHP
web applications
• Applications delivered over the web!
• Many server side components– N-tier architecture
• Very wide range of functionality– web mail– online retail sales and auction sites– wikis, discussion boards, weblogs– multi-player online role-playing games, etc…
software components of a web app
• web server– configuration files
• general processor components– e.g. PHP, ASP processor, XSLT processor
• application-specific software– servelets– scripts
data components of a web app
• databases– possibly distributed or mirrored
• session information– stateful servers retain session information– may persist in a database
• global information– shared by all or many web app processes– e.g. number of hits on the site, user profiles
file components of a web app
• web pages– html files, stylesheets– script files, applets– images
• dynamically generated pages– templates, e.g. PHP, ASP pages– xml files
• web app architecture– structure definition and global data files
design problems
• construction and testing– how do we build a web application?– what technology should we choose?
• re-use– can we use standard components?
• scalability– how will our web application cope with
• large numbers of requests?• large volumes of data exchanged?
design problems
• security– how do we protect against attack?
• viruses• malicious data access• denial of service
– different data views• user types• individual accounts• data protection
design patterns
• a design pattern is a general solution to a common software design problem
• provides a development template
• OO design patterns:– relationships and interactions between objects
• not a finished design– the pattern must be adapted to the application– cannot simply translate into code
design patterns
• originally developed for architecture– Christopher Alexander
• ideas were adapted to OO Design– Beck and Cunningham, 1987– Design Patterns: elements of Re-useable
Object-oriented software, 1994• Reprinted and analysed many times
• now widely-used in software engineering
The Model-View-Controller Pattern
• very widely used pattern
• allows separation of development effort
• model– contains data and system state
• view– presents data and system state
• controller– handles events affecting model or view
model-view-controller
• model knows little about the view– simply signals changes (alerts listeners)
• view understands the model interface– uses model methods to get update data
• controller knows model and view interfaces– updates model in response to events– updates view in response to events or changes
in the model
model-view-controller
model
view controller
event
event is passed to the controller
controller updates model and/or view
controller updates model and/or view
view queries model
model signals changes
example
• design and build a computer Monopoly game
• model– ???
• view– ???
• controller– ???
Monopoly model
• game state– board data
• properties• cards (chance and community chest)
– player data• money and properties owned, token, location
– rules• pay rent• build houses and hotels• Go to Jail
Monopoly View
• Representation of game state
• Various views possible
• Simple text– List of players, positions, properties owned,…
• Graphic presentation– Image of Monopoly Board– Visual positioning of players– Visualisation of money, properties owned,…
Monopoly view
Monopoly controllerstart game
select next player
player move
end player turn
playerbankrupt?
N
end game
gamewon?
Y
Y
N
remove player
updates tomodel and view
advantages of M-V-C
• clarity of design– model methods give an API for data and state– eases the design of view and controller
• efficient modularity– any of the components can be easily replaced
• multiple views– many views can be developed as appropriate– each uses the same API for the model
advantages of M-V-C
• easier to construct and maintain– simple (text-based) views while constructing– more views and controllers can be added– stable interfaces ease development
• distributable– natural fit with a distributed environment
• powerful user interfaces– controller supports “macro-like” interaction
with the model API
developing a M-V-C app
• build the model– public methods become the interface for views and
controller– build simple views to test the model
• build the view(s)– use simple controllers to test view and model
• build the controller– implement handling of all events
• maintain– model remains fairly stable, views and controller may
become more elaborate
M-V-C for web applications
Model for Web Applications
• model consists of data and system state
• database tables– persistent data
• session information– current system state data
• business logic (eCommerce)– rules governing the transaction
View for web applications
• view gives a presentation of the model
• client-side presentation in a browser window– (D)HTML– CSS stylesheets– server-side templates
• administrative information– server output logs
Controller for web applications
• controller handles events
• user-generated events– client-side scripting– http request processing– redirection– preprocessing
• system maintenance– web application management
M-V-C Example
PHP/CGI
WebServer
WebBrowser
presentation request processing program logic
controllerview model
two-tier client-server architecture
M-V-C Example
JSP/ASP/CF
WebServer
WebBrowser
entity
entity
database
view
controller
view/controller model
model
multi-tier client server architecture
development of absence monitoring web app
• model data– student ids and names– number of absences
• model API– list names– list names and absences– update absences
• implement as a relational database
development of absence monitoring web app
• views– attendance register– list of absences– add a student– delete a student
• implemented in a browser– DHTML interface– pages dynamically generated from model
development of absence monitoring web app
• controller– handle requests for views
• generate correct page from the database
– update the model• translate user action into a database update
– update the views• refresh browser when view changes
build the model
• design data structure• implement tables• create SQL queries
– support all required functionality
• test queries against sample data– this is a simple view
build the view
• develop server side scripts to query the database– SQL already tested is
the model API
• design web pages and embed the scripts– view now updates
from the model
build the controller
• add client side scripts– JavaScript– HTML forms– input validation
• add navigation functionality– frames– layers
• update confirmation pages
web application frameworks
web application frameworks
• technologies designed to implement web apps in M-V-C– model 2 architecture
• provide standard re-useable components for model, view and controller
• greatly ease the design of large sophisticated web apps
• significant learning curve
web application frameworks
• typically xml configuration files “glue” components into an application
• implement standard web concepts– interface features (forms)– request and response objects– sessions– database interactions
• many frameworks exist
web application frameworks
• Many frameworks are being developed…– JavaServer Faces, Struts, Webwork2– WebObjects (.NET specific)– Model Glue (ColdFusion specific)– Velocity, Fusebox, Mach II, Maypole, Catalyst,
Tapestry, ZNF, Phrame, Cocoon, Ruby on Rails, …
• Most, but not all, are based around M-V-C