1. Design Patterns Model – View – Controller

2. 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 Apple’s OS X.
Recommended structural framework pattern in J2EE.
I have used this pattern for nearly ten years.
Copyright © 2001 DeLorme
28 November 2001

3. 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

4. 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
SummaryView
+update(Observable, Object)
Copyright © 2001 DeLorme
28 November 2001

5. Transactions Happen! Controller BankAccount AccountView SummaryView
deposit()
setChanged()
notifyObservers()
update()
getBalance()
update()
getBalance()
Copyright © 2001 DeLorme
28 November 2001

6. 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

7. Architecture Diagram Model View Controller business logic Set State
Get State
Update
Event
Change View
View
model representation
Controller
user interaction
User Actions
Copyright © 2001 DeLorme
28 November 2001

8. 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.
When the implementation is sufficiently discrete, the interface can be entirely replaced.
Since the Model encapsulates both state and logic, state changes made by one interface can be seen in others.
Copyright © 2001 DeLorme
28 November 2001

9. Problems Problems of translation: Problems of the pattern:
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