Comparison
Model-view-viewmodelvsTwo-way data binding
Model-view-viewmodel
you changed a property on the viewmodel and the label updated, and no code you wrote connected the two.
A presentation model plus declarative data binding: the view binds to properties and commands on a viewmodel, and the framework propagates changes both ways. It removes the per-field wiring that MVP requires and moves the cost into a binding layer whose failures are silent — a misspelled binding path that simply shows nothing. It requires framework support to exist at all, which is the practical difference from presentation model.
Full entry →Two-way data binding
typing in the box changed the object and changing the object changed the box, and tracing which caused which was work.
A binding where updates flow in both directions between a view element and a model property. It removes an enormous amount of glue and makes the direction of causation unreadable, which is exactly why the one-way data flow argument won in the frontend and why it survived in desktop frameworks. Its worst failure is the update loop, where two bindings keep triggering each other.
Full entry →