Design Patterns Model View Controller

History
A

framework pattern for reusable applications. Depends on the Observer pattern.

First

developed by Xerox PARC for Smalltalk-80. Used by the Application Kit system in NeXTstep. Used by the Cocoa APIs for Apples OS X. Recommended structural framework pattern in J2EE.
I

have used this pattern for nearly ten years.

Copyright 2001 DeLorme 28 November 2001

Observer Pattern
Defines

a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Used to decouple the subject from the observer, since the subject needs little information to notify the observer. Can result in excessive notifications.
Copyright 2001 DeLorme 28 November 2001

Observer Class Diagram

Observable
+addObserver(Observer) +deleteObserver(Observer) +notifyObservers(Object) #hasChanged() : boolean #setChanged()

Observer
+update(Observable, Object)

AccountView
+update(Observable, Object)

BankAccount
+widthdraw(double) : long +deposit(double) : long +getBalance() : double
Copyright 2001 DeLorme 28 November 2001

SummaryView
+update(Observable, Object)

Transactions Happen!
Controller
deposit() setChanged() notifyObservers() update() getBalance() update() getBalance()

BankAccount

AccountView

SummaryView

Copyright 2001 DeLorme 28 November 2001

Observer Rocks!
The

Observer pattern allowed the BankAccount class to notify multiple views without minimal information. Observers can register themselves with their Subjects. No strings attached!
Transactions

would cause this design to collapse under spurious notifications!

Copyright 2001 DeLorme 28 November 2001

Architecture Diagram
Model
business logic Get State Update Event Change View Set

State

View
model representation
User Actions

Controller
user interaction

Copyright 2001 DeLorme 28 November 2001

Advantages
Separation

between the data layer and the interface is the key:

The view is easily replaced or expanded. Model data changes are reflected in all interfaces because all views are Observers. Better scalability since UI and application logic are separated. Distribution over a network is greatly simplified.

Copyright 2001 DeLorme 28 November 2001

Problems
Problems

of translation:

Business logic bleeds into the Controller. Observer pattern is non-obvious for EJBs. See EJBObserver by Greg Comeau.
Problems

of the pattern:

Excessive coupling between the Model and View and the Model and Controller. Frozen interfaces are hard to manage!
Copyright 2001 DeLorme 28 November 2001