OLD | NEW |
(Empty) | |
| 1 <h1 class="page_title">MVC Architecture</h1> |
| 2 <p> |
| 3 As modern browsers become more powerful with rich features, |
| 4 building full-blown web applications in JavaScript is not only feasible, |
| 5 but increasingly popular. |
| 6 Based on |
| 7 <a href="http://httparchive.org/trends.php?s=intersection&minlabel=Jan+20+2011&m
axlabel=Jan+15+2012">trends</a> |
| 8 on <a href="http://httparchive.org/">HTTP Archive</a>, |
| 9 deployed JavaScript code size has grown 45% over the course of the year. |
| 10 </p> |
| 11 <img src="{{static}}/images/jstransferrequests.png" |
| 12 width="568" |
| 13 height="292" |
| 14 alt="JS transfer size and JS requests"> |
| 15 <p> |
| 16 With JavaScript's popularity climbing, |
| 17 our client-side applications are much more complex than before. |
| 18 Application development requires collaboration from multiple developers. |
| 19 Writing <strong>maintainable</strong> and |
| 20 <strong>reusable</strong> code is crucial in the new web app era. |
| 21 The Chrome packaged app, with its rich client-side features, is no exception. |
| 22 </p> |
| 23 <p> |
| 24 Design patterns are important to write maintainable and reusable code. |
| 25 A pattern is a reusable solution that can be applied to commonly occurring probl
ems in software design — |
| 26 in our case — writing Chrome packaged apps. |
| 27 We recommend that developers decouple the app |
| 28 into a series of independent components following the MVC pattern. |
| 29 </p> |
| 30 <p> |
| 31 In the last few years, |
| 32 a series of JavaScript MVC frameworks have been developed, |
| 33 such as <a href="http://backbonejs.org/">backbone.js</a>, <a href="http://emberj
s.com/">ember.js</a>, <a href="http://angularjs.org/">AngularJS</a>, <a href="ht
tp://sencha.com/">Sencha</a>, <a href="http://kendo.com/">Kendo UI</a>, and more
. |
| 34 While they all have their unique advantages, each one of them follows some form
of MVC pattern |
| 35 with the goal of encouraging developers to write more structured JavaScript code
. |
| 36 </p> |
| 37 <h2 id="mvc">MVC pattern overview</h2> |
| 38 <p> |
| 39 MVC offers architectural benefits over standard JavaScript — |
| 40 it helps you write better organized, and therefore more maintainable code. |
| 41 This pattern has been used and extensively tested |
| 42 over multiple languages and generations of programmers. |
| 43 </p> |
| 44 <p> |
| 45 MVC is composed of three components: |
| 46 </p> |
| 47 <img src="{{static}}/images/mvc.png" |
| 48 width="466" |
| 49 height="303" |
| 50 alt="model-view-controller"> |
| 51 <h3>Model</h3> |
| 52 <p> |
| 53 Model is where the application’s data objects are stored. |
| 54 The model doesn’t know anything about views and controllers. |
| 55 When a model changes, typically it will notify its observers that a change has o
ccurred. |
| 56 </p> |
| 57 <p> |
| 58 To understand this further, let’s use the Todo list app, a simple, one page web
app that tracks your task list. |
| 59 </p> |
| 60 <br> |
| 61 <img src="{{static}}/images/todos.png" |
| 62 width="444" |
| 63 height="366" |
| 64 alt="model-view-controller"> |
| 65 <p> |
| 66 The model here represents attributes associated |
| 67 with each todo item such as description and status. |
| 68 When a new todo item is created, |
| 69 it is stored in an instance of the model. |
| 70 </p> |
| 71 <h3>View</h3> |
| 72 <p> |
| 73 View is what's presented to the users and how users interact with the app. |
| 74 The view is made with HTML, CSS, JavaScript and often templates. |
| 75 This part of your Chrome packaged app has access to the DOM. |
| 76 </p> |
| 77 <p> |
| 78 For example, in the above todo list web app, |
| 79 you can create a view that nicely presents the list of todo items to your users. |
| 80 Users can also enter a new todo item through some input format; |
| 81 however, the view doesn’t know how to update the model because that’s the contro
ller’s job. |
| 82 </p> |
| 83 <h3>Controller</h3> |
| 84 <p> |
| 85 The controller is the decision maker and the glue between the model and view. |
| 86 The controller updates the view when the model changes. |
| 87 It also adds event listeners to the view and |
| 88 updates the model when the user manipulates the view. |
| 89 </p> |
| 90 <p> |
| 91 In the todo list web app, |
| 92 when the user checks an item as completed, |
| 93 the click is forwarded to the controller. |
| 94 The controller modifies the model to mark item as completed. |
| 95 If the data needs to be persistent, it also makes an async save to the server. |
| 96 In rich client-side web app development such as Chrome packaged apps, |
| 97 keeping the data persistent in local storage is also crucial. |
| 98 In this case, the controller also handles saving the data |
| 99 to the client-side storage such as <a href="app_storage.html">FileSystem API</a>
. |
| 100 </p> |
| 101 <p> |
| 102 There are a few variations of the MVC design pattern |
| 103 such as MVP (Model–View–Presenter) |
| 104 and MVVP(Model–View–ViewModel). |
| 105 Even with the so called MVC design pattern itself, |
| 106 there is some variation between the traditional MVC pattern |
| 107 vs the modern interpretation in various programming languages. |
| 108 For example, some MVC–based frameworks will have |
| 109 the view observe the changes in the models |
| 110 while others will let the controller handle the view update. |
| 111 This article is not focused on the comparison of various implementations |
| 112 but rather on the separation–of–concerns and |
| 113 it's importance in writing modern web apps. |
| 114 </p> |
| 115 <p> |
| 116 If you are interested in learning more, |
| 117 we recommend <a href="https://plus.google.com/u/0/115133653231679625609/posts">A
ddy Osmani's</a> online book: <a href="http://addyosmani.com/resources/essential
jsdesignpatterns/book/">Learning JavaScript Design Patterns</a>. |
| 118 </p> |
| 119 <p> |
| 120 To summarize, the MVC pattern brings modularity |
| 121 to application developers and it enables: |
| 122 </p> |
| 123 <ul> |
| 124 <li>Reusable and extendable code.</li> |
| 125 <li>Separation of view logic from business logic.</li> |
| 126 <li>Allow simultaneous work between developers who are responsible |
| 127 for different components (such as UI layer and core logic).</li> |
| 128 <li>Easier to maintain.</li> |
| 129 </ul> |
| 130 <h2 id="mvcpersistence">MVC persistence patterns</h2> |
| 131 <p> |
| 132 There are many different ways of implementing persistence |
| 133 with an MVC framework, each with different trade–offs. |
| 134 When writing Chrome packaged apps, |
| 135 choose the frameworks with MVC and persistence patterns |
| 136 that feel natural to you and fit you application needs. |
| 137 </p> |
| 138 <h3>Model does its own persistence - ActiveRecord pattern</h3> |
| 139 <p> |
| 140 Popular in both server–side frameworks like Ruby on Rails, |
| 141 and client-side frameworks like |
| 142 <a href="http://backbonejs.org">Backbone.js</a> and |
| 143 <a href="http://emberjs.com/">ember.js</a>, |
| 144 the ActiveRecord pattern places the responsibility |
| 145 for persistence on the model itself |
| 146 and is typically implemented via JSON API. |
| 147 </p> |
| 148 <p> |
| 149 A slightly different take from |
| 150 having a model handle the persistence |
| 151 is to introduce a separate concept of Store and Adapter API. |
| 152 Store, Model and |
| 153 Adapter (in some frameworks it is called Proxy) |
| 154 work hand by hand. |
| 155 Store is the repository that holds the loaded models, |
| 156 and it also provides functions such as creating, |
| 157 querying and filtering the model instances contained within it. |
| 158 </p> |
| 159 <p> |
| 160 An adapter, or a proxy, receives the requests from a store and |
| 161 translates them into appropriate actions to take |
| 162 against your persistent data layer |
| 163 (such as JSON API). |
| 164 This is interesting in the modern web app design |
| 165 because you often interact with more than one persistent data layer |
| 166 such as a remote server and browser’s local storage. |
| 167 Chrome package apps provides both |
| 168 <a href="storage.html">Chrome Storage API</a> and |
| 169 <a href="fileSystem.html">HTML 5 fileSystem API</a> for client side storage. |
| 170 </p> |
| 171 <p>Pros:</p> |
| 172 <ul> |
| 173 <li>Simple to use and understand.</li> |
| 174 </ul> |
| 175 <p> |
| 176 Cons: |
| 177 </p> |
| 178 <ul> |
| 179 <li>Hard to test since the persistence layer is ‘baked’ into the object
hierarchy.</li> |
| 180 <li>Having different objects use different persistent stores is difficul
t |
| 181 (for example, FileSystem APIs vs indexedDB vs server–side)
.</li> |
| 182 <li>Reusing Model in other applications may create conflicts, |
| 183 such as sharing a single Customer class between two different vi
ews, |
| 184 each view wanting to save to different places.</li> |
| 185 </ul> |
| 186 <h3>Controller does persistence</h3> |
| 187 <p> |
| 188 In this pattern, the controller holds a reference |
| 189 to both the model and a datastore |
| 190 and is responsible for keeping the model persisted. |
| 191 The controller responds to lifecycle events like Load, Save, Delete, |
| 192 and issues commands to the datastore to fetch or update the model. |
| 193 </p> |
| 194 <p> |
| 195 Pros: |
| 196 </p> |
| 197 <ul> |
| 198 <li>Easier to test, controller can be passed a mock datastore to write t
ests against.</li> |
| 199 <li>The same model can be reused with multiple datastores just by constr
ucting controllers with different datastores.</li> |
| 200 </ul> |
| 201 <p> |
| 202 Cons: |
| 203 </p> |
| 204 <ul> |
| 205 <li>Code can be more complex to maintain.</li> |
| 206 </ul> |
| 207 <h3>AppController does persistence</h3> |
| 208 <p> |
| 209 In some patterns, there is a supervising controller responsible |
| 210 for navigating between one MVC and another. |
| 211 The AppController decides, for example, |
| 212 that a ‘Back’ button moves the client from an editing screen |
| 213 (which contains MVC widgets/formats), |
| 214 to a settings screen. |
| 215 </p> |
| 216 <p> |
| 217 In the AppController pattern, |
| 218 the AppController responds to events |
| 219 and changes the app’s current screen by issuing a call |
| 220 to the datastore to load any models needed and |
| 221 constructing all of the matching views and controllers for that screen. |
| 222 </p> |
| 223 <p> |
| 224 Pros: |
| 225 </p> |
| 226 <ul> |
| 227 <li>Moves persistence layer even higher up the stack where it can be eas
ily changed.</li> |
| 228 <li>Doesn’t pollute lower level controllers like a DatePickerController
with the need to know about persistence.</li> |
| 229 <li>Aligns nicely with an ‘Intent’ model. |
| 230 Each AppController corresponds to an intent, like “ChoosePhoto”,
or “SendMessage”. |
| 231 The Intent contains a reference to the model data needed (Custom
er#123) and |
| 232 the type of CRUD operation (load, save, delete, and so on).</li> |
| 233 </ul> |
| 234 <p> |
| 235 Cons: |
| 236 </p> |
| 237 <ul> |
| 238 <li>Each ‘Page/Screen’ of the app now requires a lot of boilerplate to w
rite or update: Model, View, Controller, AppController.</li> |
| 239 </ul> |
| 240 <h3>Recommended MVC frameworks</h3> |
| 241 <p> |
| 242 MVC is crucial to designing Chrome packaged apps. |
| 243 We recommend the following <a href="app_csp.html">CSP–Compliant</a> MVC fr
ameworks |
| 244 for writing secure and scalable Chrome packaged apps: |
| 245 </p> |
| 246 <ul> |
| 247 <li><a href="http://angularjs.org/">AngularJS</a> |
| 248 (<a href="https://github.com/GoogleChrome/textdrive-app">Text Dr
ive Reference App</a>)</li> |
| 249 <li><a href="http://kendo.com/">Kendo UI</a> |
| 250 (<a href="https://github.com/GoogleChrome/kendo-photo-booth-app"
>Photo Booth Reference App</a>)</li> |
| 251 <li><a href="http://www.sencha.com/">Sencha</a> |
| 252 (<a href="https://github.com/GoogleChrome/sencha-video-player-ap
p">Video Player Reference App</a>)</li> |
| 253 </ul> |
| 254 <h2 id="resources">Useful resources</h2> |
| 255 <h3>Online</h3> |
| 256 <ul> |
| 257 <li><a href="http://www.html5rocks.com/">HTML5Rocks.com</a></li> |
| 258 <li><a href="http://addyosmani.com/resources/essentialjsdesignpatterns/b
ook/">Learning JavaScript Design Patterns</a> |
| 259 (by Addy Osmani)</li> |
| 260 <li><a href="http://addyosmani.github.com/todomvc/">TodoMVC</a></li> |
| 261 </ul> |
| 262 <h3>Books</h3> |
| 263 <ul> |
| 264 <li><a href="http://www.amazon.com/JavaScript-Web-Applications-Alex-MacC
aw/dp/144930351X">JavaScript Web Applications</a> |
| 265 (By Alex MacCaw)</li> |
| 266 <li><a href="http://www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/d
p/0596806752/ref=pd_sim_b_2">JavaScript Patterns</a> |
| 267 (By Stoyan Stefonov)</li> |
| 268 <li><a href="http://www.amazon.com/Maintainable-JavaScript-Nicholas-C-Za
kas/dp/1449327680">Maintainable JavaScript</a> |
| 269 (By Nicolas Z. Zakas)</li> |
| 270 </ul> |
| 271 <p class="backtotop"><a href="#top">Back to top</a></p> |
OLD | NEW |