Database can be replaced by another that supports the same interface
Architectural stylePresentation tier complexity
As long as same interface, this is still a binary-replaceable component
Model-view-controller
Component diagramFeatures
Separated presentation
Decoupled model and view (replaceable components)
Multiple (possibly simultaneous) views supported
Example
Mission Control terminal
A vehicle (unmanned aircraft) is flown by a pilot interfacing with a computer terminal on the ground
Vehicle communicates with ground station via radio signals
Actuation commands (uplink): change throttle, angle flaps, etc.
Sensor measurements (downlink): air speed, GPS position, actuator settings, etc.
View
Graphical user interface shows model properties (sensor readings, derived state) as instrument dials and provides input widgets for commanding actuators
Model
Maintain record of state of vehicle
Computes derived properties of vehicle (rate of turn, predicted trajectory, …)
Updates state in response to actions from controller (e.g. new telemetry received)
Provides view with information to be displayed to user
Different vehicles will need different models but might not require new views or controllers.
Controller: Pilot wishes to change flap angle to 20 deg to increase lift and accommodate a slower speed for landing.
View sends message to controller: setFlaps(20)
Controller sends radio command to vehicle: setFlaps(20)
Vehicle acts on command and replies to controller: flapsSet(20)
Controller relays telemetry to model: flapsSet(20)
Model updates state and recomputes stall speed
Model notifies view of new state (flap setting, stall speed)
View displays new state in user interface
View
Presents application state and controls to user
Typically subscribes to model for notifications of state changes
“Observer pattern”
Responsible for rendering to a particular interface
Drawing graphics, generating HTML, printing text
Sends user input to controller
A single model can support multiple views
Example: web app, native app
Model
Records state of application and notifies subscribers
Responds to instructions to change state (from controller)
Does not depend on either controller or view
State may be stored in objects or databases
May be responsible for some application logic (e.g. input validation)
Controller
Manages user input and navigation
Defines application behavior
Maps user actions to changes in state (model) or view
May interact with external services via APIs
May be responsible for some application logic (e.g. input validation)
Variety in distribution of duties between model and controller
Publish-Subscribe
Overview
Event-driven control
Application responds to external stimuli and timeouts
No centralized orchestration
Very loose coupling – components communicate via message broker
Easy to extend
Difficult to analyze (observer pattern)
No control over what (if any) code responds to an event
Potential for conflicts (multiple components respond in incompatible ways)
