http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
http://en.wikipedia.org/wiki/Model_View_ViewModel
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
http://msdn.microsoft.com/en-us/library/gg405484(v=pandp.40).aspx
http://addyosmani.com/blog/understanding-mvvm-a-guide-for-javascript-developers/
http://visualstudiomagazine.com/articles/2011/08/15/fundamental-mvvm.aspx
http://www.codeproject.com/Articles/278901/MVVM-Pattern-Made-Simple
http://csharperimage.jeremylikness.com/2010/04/model-view-viewmodel-mvvm-explained.html
http://channel9.msdn.com/coding4fun/blog/MVVM-Diagram-Designer
http://books.zkoss.org/wiki/ZK_Developer's_Reference/MVVM
http://channel9.msdn.com/Events/MIX/MIX10/EX14
http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
http://msdn.microsoft.com/en-us/library/gg405484%28v=pandp.40%29.aspx
http://www.codeproject.com/Articles/278901/MVVM-Pattern-Made-Simple
http://www.lhotka.net/weblog/UsingTheMVVMPatternRequiresAFramework.aspx
http://visualstudiomagazine.com/articles/2011/08/15/fundamental-mvvm.aspx
http://addyosmani.com/blog/understanding-mvvm-a-guide-for-javascript-developers/
http://thatextramile.be/blog/2010/07/the-mvvm-pattern-is-highly-overrated
http://knockoutjs.com/documentation/observables.html
In MVC, the M represent the logic for dealing with the data, storing it in the database, retrieving it from the database, etc. The V represent the logic for rendering. The C represents the Controller which is business logic that link the M and the V together.
With the event of the Internet, the View logic now resides on the client-side, and technically the definition of View (or rendering logic) is still vaque, because when the data is delivered to the browser, there can be multiple ways for JavaScript code to consume and display that data. With the proliferation of screen sizes and devices (desktops, laptops, tablets, smart phones, and other mobile devices), a web application can have multiple views (one for each type of device). How each view render the data is specific to that device. However, the way that each view consume the data, or interact with the server, in most cases, should be consistent. The MVVM pattern further separate the logic for consuming the data from the rendering logic. It introduces the ViewModel which faciliate how the view consume data. JavaScript libraries such as ExtJS and Kendo UI have a concept of "data source" so that advanced UI widgets / components knows how to get data from the server, and possibly update that data on the server when the user interact with the application. Ideally, developer should not even have to write JavaScript code that fetch values from the DOM, and making AJAX call to the server to save the data. The developers still have to provide the logic for saving the data, as part of the definition for the data source, but the developers should not have to get the data from the DOM. Client-side validation is done by the framework, outside of the "data source" definition. We still need to perform server-side validation. The "data source" represents the ViewModel, which does not care how the View render the data. The View and ViewModel work together through some kind of observer / listener mechanism. For example, when the data is changed in the form, the framework (through data-binding) fire an event, and the ViewModel which is listening for that event, is notified of the change, and can carry out whatever it needs to do to update the database. The data source either extends the ViewModel or being used by the ViewModels. Interaction between the form and data source is accomplished via data-binding.
Model View Presenter (MVP) is a variation of the Model-View-Controller (MVC) pattern. With MVP, what you see on the screen is the View. The data its displays is the model, and Presenter hooks the two together. The view relies on the Presenter to populate it with the model data, react to the user input, provide input validation (perhaps by delegating to the model), and other such tasks.
The Presentation Model (PM) pattern is similar to MVP in that it separates a view from its behavior and state. The interesting part of the PM pattern is that an abstraction of a view is created, called the Presentation Model. A view, then, becomes merely a rendering of a Presentation Model. The PM frequently updates the view so that the two stay in sync with each other. That synchronization logic exist as code in the Presentation Model classes.
MVVM is identical to the Presentation Model, in that both patterns feature an abstraction of a view, which contains the view's state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF to simplify the creation of user interfaces. In that sense, I consider MVVM to be a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms.
Unlike the Presenter in MVP, a ViewModel does not need a reference to a view. The view binds to properties on a ViewModel, which, in turn, exposes data contained in model objects and other state specific to the view. The bindings between view and ViewModel are simple to construct because a ViewModel object is set as the DataContext of a view. If property values in the ViewModel change, those new values automatically propagate to the view via data binding. When the user clicks a button in the View, a command on the ViewModel executes to perform the requested action. The ViewModel, never the View, performs all modifications made to the model data.
The view classes have no idea that the model classes exist, while the ViewModel and model are unaware of the view. In fact, the model is completely oblivious to the fact that the ViewModel and view exist. This is a very loosely coupled design, which pays dividends in many ways.
Data binding is crucial. The single most important aspect of WPF that makes MVVM a great pattern to use is the data binding infrastructure. By binding properties of a view to a ViewModel, you get loose coupling between the two and entirely remove the need for writing code in a ViewModel that directly updates a view. The data binding system also supports input validation, which provides a standardized way of transmitting validation errors to a view.
Two other features of WPF that make this pattern so usable are data templates and the resource system. Data templates apply Views to ViewModel objects shown in the user interface. You can declare templates in XAML and let the resource system automatically locate and apply those templates for you at run time.
MVVM is also popular because ViewModel classes are easy to unit test. When an application's interaction logic lives in a set of ViewModel classes, you can easily write code that tests it. In a sense, Views and unit tests are just two different types of ViewModel consumers. Having a suite of tests for an application's ViewModels provides free and fast regression testing, which helps reduce the cost of maintaining an application over time.
In addition to promoting the creation of automated regression tests, the testability of ViewModel classes can assist in properly designing user interfaces that are easy to skin. When you are designing an application, you can often decide whether something should be in the view or the ViewModel by imagining that you want to write a unit test to consume the ViewModel. If you can write unit tests for the ViewModel without creating any UI objects, you can also completely skin the ViewModel because it has no dependencies on specific visual elements.
Lastly, for developers who work with visual designers, using MVVM makes it much easier to create a smooth designer/developer workflow. Since a view is just an arbitrary consumer of a ViewModel, it is easy to just rip one view out and drop in a new view to render a ViewModel. This simple step allows for rapid prototyping and evaluation of user interfaces made by the designers.
The development team can focus on creating robust ViewModel classes, and the design team can focus on making user-friendly Views. Connecting the output of both teams can involve little more than ensuring that the correct bindings exist in a view's XAML file.
GWT: using back-end code which produce front-end code. Using front-end code to reduce back-end logic. The database is just for storage / persistency. We still need server side security. Need to understand GWT.
