tailieunhanh - Design Patterns Model – View – Controller

Patterns Model – View – Controller defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Design Patterns Model – View – Controller provides about history, observer pattern, observer class diagram, transactions happen, observer rocks, architecture diagram, advantages, problems. | Design Patterns Model – View – Controller Copyright © 2001 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 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 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 SummaryView +update(Observable, Object) Copyright © 2001 DeLorme 28 November 2001 Transactions Happen! Controller BankAccount AccountView SummaryView deposit() setChanged() notifyObservers() update() update() getBalance() getBalance() 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 View model representation Model business logic Controller user interaction Update Event User Actions Change View Set State Get State 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. 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 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!