3. "Logical" versus "Physical" User Interface

The idea of a logical UI model, also called view model, was first proposed (under a different name) by Martin Fowler in his post on the Presentation Model in 2004, where he stated that the view model "pulls the state and behavior of the view out" into a view model class. This means that the logical content of a UI is abstracted out from a concrete "physical" UI, which has specific renderings of the logical UI fields and "commands" (user actions). Logical UI fields are rendered in the form of UI widgets that have their own state, while logical UI commands are rendered in the form of UI event listeners.

Later, in 2005, the view model concept was adopted by John Gossman (from Microsoft) in his blog post Introduction to Model/View/ViewModel pattern for building WPF Apps and popularized under the architecture pattern acronym "MVVM".

In a user interface for a Create/Retrieve/Update/Delete (CRUD) data management operation, a view model class would be bound to exactly one model class, but could support more than one view (class). A view model class would have properties that are bound to the widgets of the supported view(s), using either one-way or two-way data binding, and methods that are bound to corresponding commands (command binding).

Typically, most view fields directly correspond to properties of the underlying model class, although they may have a different name. For these fields (or view model properties), a data binding to the corresponding model class properties is needed. But a view model class may also have additional properties, some of them may represent view fields that are not bound to a model class property, while others may represent auxiliary fields that are not rendered in the UI.

The methods of a view model class are invoked when a corresponding command has been issued by the user through creating a UI event that triggers an event listener, to which the command has been bound.

Dividing up the overall UI code into a view model part and a view part creates a certain overhead that may not be justified in certain cases. While the use of a view model is justified for all apps with CRUD data management operations, it may, for instance, not be justified for visualization user interfaces.

The main benefits of view models are that they facilitate: (1) UI design, (2) the testing of the UI logic, and (3) the maintenance of the UI.