Model View Controller (MVC) Architecture

Advanced Programming Practices

• Includes Model View Controller Architecture and Observer Pattern

Model View Controller (MVC) Architecture

• Introduced by Trygve Reenskaug at the Xerox Palo Alto Research Center in 1979
• Is part of the Smalltalk programming environment
• Used for object-oriented designs with user interaction
• Is a three-tier architectural model

MVC: Model

• Manages the behavior and data of the application domain
• Responds to requests for information about its state, usually from the view
• Responds to instructions to change state, usually from the controller
• In event-driven systems, the model notifies observers (usually views) when information changes, enabling reactions
• Serves as a software approximation of a real-world process in enterprise software
• Represented by classes defining game entities in a game

MVC: View

• Renders the model into a suitable form for visualization or interaction, typically a user interface element
• Multiple views can exist for a single model element for different purposes
• Renders the contents of a portion of the model’s data
• Must update its presentation if the model data changes
• Achieved using a push model, where the view registers with the model for change notifications (Observer pattern), or a pull model, where the view retrieves the most current data as needed

MVC: Controller

• Receives user input and initiates a response using appropriate model objects
• Accepts input (events or data) from the user and instructs the model to perform actions based on that input
• Translates user interactions with the associated view into actions the model can perform, potentially using additional/changed data from a user-interactive view
• May spawn new views upon user demand

MVC: Interactions Between Model, View and Controller

• The model objects are created, with each representing a portion of the business model state
• The views register as observers on the model objects
• Changes to the model objects' data immediately result in a broadcast change notification to all associated views (in the push model)
• The model is unaware of the view or controller and simply broadcasts change notifications
• The controller is bound to a view
• This allows the controller to react to any user interaction provided by that view
• User actions on the view call a method in the controller class
• The controller is given a reference to the underlying model, which enables triggering the model’s behavior functions and/or state change when its methods are called

User Interaction with the View

• The view recognizes a GUI action (e.g., a button push or scroll bar drag)
• This is done using a listener method registered to be called when such an action occurs, varying depending on the technology or library used
• The view calls the appropriate method in the controller using the listener method
• The controller translates the signal into an appropriate action in the model
• The model is possibly updated in a way appropriate to the user's action
• Altered model elements notify registered observers of the change
• In some architectures, the controller may update the view

Observer Pattern: Motivation

• The need to inform certain objects about changes in other objects is frequent
• A good design decouples as much as possible and reduces dependencies
• This pattern is used when a subject needs to be observed by one or more observers

Observer Pattern: Intent

• Defines a one-to-many dependency between objects
• When one object changes state, all its dependents are notified and updated automatically
• The Observer Pattern is a cornerstone of the Model-View-Controller architectural design
• The Model implements the business logic
• The Views are implemented as Observers and are uncoupled as much as possible from the Model components

Observer Pattern: Design

• The participant classes are:
• Subject: An interface or abstract class that defines operations for attaching and detaching observers from the client, often referred to as "Observable"
• ConcreteSubject: A concrete Subject class that maintains the state of the observed object
• It notifies attached observers when its state changes, and in MVC, these classes are the Model classes with attached Views
• Observer: An interface or abstract class that defines the operations to notify registered Observer objects
• ConcreteObserver: Concrete Observer subclasses that attach to a particular Subject class

Observer Pattern: Behavior

• The client class instantiates the ConcreteObservable object
• The client class instantiates and attaches the concrete observers to the ConcreteObservable object using methods defined in the Observable interface
• The subject notifies all attached Observers using the methods defined in the Observer interface, each time the observable state of the subject changes
• Adding a new Observer only requires instantiating it in the client class and attaching it to the Observable object
• Already created classes stay unchanged

Observer Pattern: Implementation

• An interface (or abstract class)
• Declares an update() method used polymorphically and must be overridden by all implementing classes
• Observable base class implementation
• Provides the attach/detach mechanism
• Provides the notification mechanism

Observer Pattern: Model Classes

• They implement the business model
• Made ConcreteObservable, they must:
• Inherit attach/detach/notification mechanisms from the Observable class
• Notify their Observers when an observable part their state changes

Observer Pattern: View Classes

• Implement the displaying of information relevant to the user from Model objects
• To be made ConcreteObserver, must:
• Implement Observer interface
• Implement the update() method declared in Observer interface

Controller: Implementation

• Implements the control flow between the Model object and the View object
• Interacts with the user to get their input used to set the clock's operation
• Triggers methods of the clock to trigger the clock's operation
• While not directly interacting with the View in the example, the Controller usually does interact with it

MVC: Putting It All Together

• The Model/View/Controller objects are created and connected for the program's lifetime
• Depending on the application, Views/Controllers may be created/removed by user actions