Design Patterns Model View Controller Christian Ratliff cratliffdelorme









- Slides: 9
Design Patterns Model – View – Controller Christian Ratliff cratliff@delorme. com Senior Technology Architect Core Libraries Group, De. Lorme 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 Ne. XTstep. ► Used by the Cocoa APIs for Apple’s OS X. ► Recommended structural framework pattern in J 2 EE. ►I have used this pattern for nearly ten years. Copyright © 2001 De. Lorme 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 De. Lorme 28 November 2001
Observer Class Diagram Observable +add. Observer(Observer) +delete. Observer(Observer) +notify. Observers(Object) #has. Changed() : boolean #set. Changed() Bank. Account +widthdraw(double) : long +deposit(double) : long +get. Balance() : double Copyright © 2001 De. Lorme 28 November 2001 Observer +update(Observable, Object) Account. View +update(Observable, Object) Summary. View +update(Observable, Object)
Transactions Happen! Controller Bank. Account. View deposit() set. Changed() notify. Observers() update() get. Balance() Copyright © 2001 De. Lorme 28 November 2001 Summary. View
Observer Rocks! ► The Observer pattern allowed the Bank. Account 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 De. Lorme 28 November 2001
Architecture Diagram Model business logic Get State Event View model representation Copyright © 2001 De. Lorme 28 November 2001 Set Update User Actions Change 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 De. Lorme 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 De. Lorme 28 November 2001