close

Вход

Забыли?

вход по аккаунту

?

Model – View – Controller

код для вставкиСкачать
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 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()
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
Event
View
model representation
Copyright В© 2001 DeLorme
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 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
Документ
Категория
Презентации
Просмотров
2
Размер файла
1 048 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа