Model - View - Controller

Design Patterns Model View Controller Christian Ratliff [email protected] Senior Technology Architect Core Libraries Group, DeLorme 28 November 2001 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() BankAccount +widthdraw(double) : long +deposit(double) : long +getBalance() : double Copyright 2001 DeLorme 28 November 2001 Observer

+update(Observable, Object) AccountView +update(Observable, Object) SummaryView +update(Observable, Object) Transactions Happen! Controller BankAccount AccountView deposit()

setChanged() notifyObservers() update() getBalance() update() getBalance() Copyright 2001 DeLorme 28 November 2001 SummaryView 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 View model representation Copyright 2001 DeLorme

28 November 2001 Updat e Event User Action s Set Chang e View State Controller user interaction

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