Please sign in to comment.
- Loading branch information...
|@@ -3280,7 +3280,7 @@ <h2>MVVM With Looser Data-Bindings</h2>|
|<p>Neil Kerkin has put together a complete TodoMVC demo app using the above, which can be accessed and played around with <a href="http://jsfiddle.net/nkerkin/hmq7D/light/">here</a>.</p>|
|<p>Whilst it may look like quite a lot of work in the explanation above, now that you have a generic <code>getBindings</code> method written, it’s a lot more trivial to simply re-use it and use data-classes rather than strict data-bindings for writing your KnockoutJS applications instead. The net result is hopefully cleaner markup with your data bindings being shifted from the View to a bindings object instead.</p>|
|<h2>MVC Vs. MVP Vs. MVVM</h2>|
|-<p>Both MVP and MVVM are derivatives of MVC. The key difference between it and it’s derivatives are the dependency each layer has on other layers as well as how tightly bound they are to each other.</p>|
|+<p>Both MVP and MVVM are derivatives of MVC. The key difference between it and its derivatives is the dependency each layer has on other layers as well as how tightly bound they are to each other.</p>|
|<p>In MVC, the View sits on top of our architecture with the controller laying below this. Models sit below the controller and so our Views know about our controllers and controllers know about Models. Here, our Views have direct access to Models. Exposing the complete Model to the View however may have security and performance costs, depending on the complexity of our application. MVVM attempts to avoid these issues.</p>|
|<p>In MVP, the role of the controller is replaced with a Presenter. Presenters sit at the same level as views, listening to events from both the View and model and mediating the actions between them. Unlike MVVM, there isn’t a mechanism for binding Views to ViewModels, so we instead rely on each View implementing an interface allowing the Presenter to interact with the View.</p>|
|<p>MVVM consequently allows us to create View-specific subsets of a Model which can contain state and logic information, avoiding the need to expose the entire Model to a View. Unlike MVP’s Presenter, a ViewModel is not required to reference a View. The View can bind to properties on the ViewModel which in turn expose data contained in Models to the View. As we’ve mentioned, the abstraction of the View means there is less logic required in the code behind it.</p>|