Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Modelling and Design (Presentation (Application controller (2…
Software Modelling and Design
Presentation
Clear separation between model and upper layer; Less separation between controller/presenter
Model View Presenter (MVP): View is managed by the presenter
Model View Controller(MVC): View directly queries the model
Patterns for Input Controller
Page Controller
Controller responsibilities
Extract user data from POST or GET
Invoke appropriate methods in domain layer / external services to perform the appropriate actions based on the user action
Determine which view to display and forward the model information to it
Pros
Easy to understand
Simple to develop
Cons
Duplication of logic -> minimise by having parent classes that handle generic logic
Complex logic in controller
Cannot dynamically add new pages as controllers are static objects
Each web page / action of the web page will have its own controller
Front Controller
A controller that handles all requests for a website
Generic operations e.g. security checking and internationalisation have to be performed regardless of the view that is displayed
Implementation
Handler: receive request and statically/dynamically identify the appropriate command class to execute
Static identification: URL parsed to identify the command; appropriate command object created based on conditional logic
Dynamic identification: dynamic object instantiation used based on the command associated with the URL
Command hierarchy
Pros
Single entry point: easier web server configuration
Ease of extension: dynamic command instantiation can add new commands at runtime
Cons
Complex design
Works well for simple page transition logic
Patterns for View
Template View
Render information into HTML by embedding markers in an HTML page
Static part of the page acts as a template; dynamic content created through programming logic embedded in markers
Pros
Simple: easy to design; programming task simplified
Cons
Reduced maintainability: hard for non-programmers to design/maintain views
Promotes bad design practises: code is not well encapsulated and does not follow modularity and layering principles -> discourages reuse
Challenging to test: difficult to isolate code for unit testing; generally tested within a web server
Focuses structure of the display as a template; based on the output
JSP, ASP, PHP
Transform View
Processes domain data element by element and transforms it into HTML
Focuses on the structure of domain data -> transformed to different display formats; based on input
XSLT (render elements in XML), Javascript (XML/JSON)
Pros
Portability: language independent; views are more standardised as they are only tied to an XML output of the domain object
Encapsulation: logic in the view is limited to displaying
Improved testability: can be tested independent from the web server
Cons
Complex programming: harder implementation; expertise in XSLT
Two Step View
1st stage: transform domain-oriented XML to presentation-orientation XML
2nd stage: render presentation-oriented XML in HTML
Alternative
Domain-oriented classes: model domain information independent of presentation
Presentation-oriented classes: model presentation elementes
Domain-oriented objects translated into presentation-oriented objects, which are presented as the view
Pros
Improved maintainability: easier to make global changes to the view format due to good encapsulation
Cons
Complex design
Complex implementation
Application controller
Good for applications that require more complex screen navigation
Handles flow of logic -> input controller calls the application controller to get the domain object and the view for the particular command
2 responsibilities
Decide which domain logic object to run
Decide the view for displaying the response
Pros
Simplified input controller: enables handling the complex screen navigation logic
Less duplicated code: code is less likely to be dispersed around the application due to the central design
Cons
Complex: over-complicates the design when screen transition is relatively simple
Well-suited for Front Controller
#
Sessions
Problem
Cannot maintain an object per session -> large number of clients simultaneously connecting to the serves; inactive time between requests -> large number of objects in memory
Need to support states using servers that are stateless
Client Session State
Store session state on client instead of server
3 ways with a HTML interface as the client
URL parameters: works well for small amounts of data; does not scale well
Hidden fields: data sent as a hidden field in serialised form
Cookies: sent back and forth automatically
Pros
Resilient to server failures
Works well with server clusters
Cons
Does not scale well for large amounts of data: all relevant data must be sent with each request
Vulnerable security: data can be viewed/tampered with as it is sent across a network
Server Session State
Keeps session state on a server system in a serialised form
An object maintained in the server for each object
Server maintains a map of objects indexed by the session ID
Assumes server has enough memory' only one server
Pros
Simple to implement and intuitive
Cons
Does not work with failover and clustering
Database Session State
Store session data as committed data in the database
Separate session data from already committed data
Additional field: pending flag / session id to each record; need to define a database view because of NOT NULL clause for queries
Additional table: each table has an additional table to maintain pending data; adds complexity of maintaining two sets of tables
Need to clean data for cancelled/abandoned sessions
Cencelled: remove data related to session ID
Abandoned: need timeout mechanisms
Pros
Can easily handle clustering and failover
Cons
Impact performance due to having to pull data from the DB with each request. Can use caching to solve this
Difficult to implement compared to server session state
Concurrency
Problem with concurrency
Interference / lost updates: when >2 processes write data to the same location in quick succession
Inconsistent read: process reads data from multiple places while another process is updating it
Deadlock: when processes are mutually waiting on data that each other has locked
Transactional resources
System transaction categories
Request transaction: spans 1 request to the system
Long transaction: >1 request
Late transaction: does as much reading as possible and updates as late as possible -> open to inconsistent reads
Lock escalation: entire table locked if DB is asked to lock more rows than it can handle
Levels of transactions
Transactional resource transaction: supported by the underlying transactional resource
System transaction: Brings together multiple transactional resource transactions
Business transaction: enterprise level that bring several system transactions
Optimistic offline lock
Prevents conflicts between concurrent business transactions by detecting a conflict and rolling back the transaction
Late transaction pattern
Checks by confirming a loaded record has not be changed by other sessions
Implementation
Associate a version number with each record in the DB
When record is read, note version number store in session state
Make changes to record
Before writing the record, read version number of that record in the table
If two version numbers are equivalent, record has not changed
Obtain lock on rows, update data, increment version number
If two version numbers are different, another process has modified the record -> fail the transaction and do not write to DB
Pros
Good liveness
Simple to implement extra column + check of version numbers
Cons
Lost work/data
Pessimistic offline lock
Prevents conflicts between concurrent business transactions by allowing one business transaction at a time to access data
Implementation
Determine type of lock
Exclusive write lock: acquire lock to write; anyone can read -> has inconsistent reads
Exclusive read lock: lock must be obtained to read/write -> prevents inconsistent reads
Read/write lock: must have locks for read/write, but multiple processes can acquire a read lock at the same time. Write lock can only be acquired if no process is reading and vice versa
Tradeoff between liveness vs data integrity
Define a lock manager
Define the lock protocol