Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Structuring a Client-Side App

119 vues

Publié le

Lecture from 6.170 Software Studio (MIT CSAIL Fall 2015), demonstrating model/view separation in a single-page JavaScript application.

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Structuring a Client-Side App

  1. 1. Structuring a Client-Side App 6.170 Software Studio Fall 2015 Eirik Bakke
  2. 2. Objectives • After today’s class, you should understand what a model and a view is, and how to separate the two. • You should understand the subscriber pattern. • We will also see events, DOM building, unit testing, and the object construction idiom in action. • Today’s complete app example is relevant to both the Game of Life and the Fritter assignments
  3. 3. Today’s Example (don’t look at the source yet—spoilers! :-) http://shoutkey.com/even
  4. 4. How would you structure this app?
  5. 5. Common User Interface Architectures
  6. 6. Spaghetti Code
  7. 7. • Mixes data and presentation • Everything depends on everything • State is everywhere • Repeats logic • Small features require changes throughout codebase Spaghetti Code
  8. 8. Model/View/Controller (MVC)
  9. 9. Model/ViewController (from Java’s Swing toolkit)
  10. 10. View/ViewModel/Model (e.g. the Knockout framework)
  11. 11. The Point Is View (Presentation/ User Interface) Model (Underlying Data) • Keep the model and the view separate • Your model should not depend on your view • You should be able to write and test your model without writing a line of HTML or CSS (or other user interface code).
  12. 12. Back to Our Example
  13. 13. gradewidget.js (view) gradebook.js (model) • Our app consists of two separate modules • The model does not depend on the view • We will write and rigorously test our model, gradebook.js, before doing any work on the view (gradewidget.js) Back to Our Example
  14. 14. gradewidget.js (view) gradebook.js (model) Back to Our Example grademain.js tests.js depends-on
  15. 15. gradewidget.js gradewidget.css (view) gradebook.js (model) Back to Our Example index.html grademain.js tests.html tests.js depends-on
  16. 16. Implementation Steps 1. Basic model class 2. Robust model class, unit tests 3. Documented model class 4. Read-only grade widget—the view 5. Editable grade widget 6. Two widgets, one model (buggy) 7. Subscriber pattern 8. Reconfigure one of the widgets shoutkey.com/a sparagus
  17. 17. Basic Model Class shoutkey.com/a sparagus
  18. 18. Robust Model Class, Unit Tests shoutkey.com/a sparagus
  19. 19. Robust Model Class, Unit Tests shoutkey.com/a sparagus
  20. 20. Robust Model Class, Unit Tests shoutkey.com/a sparagus
  21. 21. Documented Model Class shoutkey.com/a sparagus
  22. 22. Read-Only Grade Widget (the “view”)
  23. 23. Read-Only Grade Widget (the “view”)
  24. 24. Read-Only Grade Widget (the “view”)
  25. 25. Read-Only Grade Widget (the “view”)
  26. 26. Editable Grade Widget
  27. 27. Editable Grade Widget
  28. 28. Editable Grade Widget new grade set on the model, not on the view!
  29. 29. Two Widgets, One Model (buggy)
  30. 30. What’s the bug?
  31. 31. Challenge: Fix the Bug tinyurl.com/ pq9gm8v
  32. 32. Subscriber Pattern gradewidget.js (view) gradebook.js (model)
  33. 33. Subscriber Pattern • The subscriber pattern is used to notify the view of changes in the model, without requiring the model to depend on the view • Subscribers are analogous to DOM event handlers; except the events are on changes to your model, and your model class is responsible for managing and calling subscribers. • Also known as “observer” pattern or “publish- subscribe” pattern
  34. 34. Fixing the bug: Subscriber Pattern gradebook.js
  35. 35. Fixing the bug: Subscriber Pattern gradewidget.js
  36. 36. Reconfigure One of the Widgets
  37. 37. Reconfigure One of the Widgets
  38. 38. Reconfigure One of the Widgets
  39. 39. Conclusion • Keep your app’s data (the “model”) separate from its user interface (the “view”) • The model should not depend on the view • Write and test the model, with unit tests and runtime checks, before writing any user interface code • The subscriber pattern can be used to notify the view of changes in the model, without requiring the model to depend on the view • When the user edits data, apply the change to the model, not the view

×