The design pattern uses some technical capabilities of a modern UI technolgy like (bi-directional) data-binding and descriptive UI declaration to simplify the development of the UI and to make testing UI code easier.
JavaFX in version 2 supports both of these capabilities: It includes Properties and Data-Bindings and FXML, a xml dialect to create the UI for JavaFX.
At the moment our MvvmFX-library is at the very beginnning. We are trying out what is possible and what is not. We would be very pleased if you like to give it a try. You can find it on github: https://github.com/sialcasa/mvvmFX
The MVVM Design Pattern
Let’s start with the View. With MVVM the view has to be silly. It may not contain any logic but only describe what is visible in the UI.
The UI specific logic is developed only in the ViewModel. The viewmodel contains the whole state of the UI and the logic that updates and changes this state. It provides the state to the outside in the form of Properties.
The view can now bind itself to the properties of the ViewModel. When the state of the viewmodel changes the view is automatically updated because of the binding.
The viewmodel knows the model. How exactly the model is created isn’t part of the MVVM pattern. It is the interface to the business logic and the rest of the application. The viewmodel takes the informations that are needed to be presented in the view from the model and brings that informations in the right form in which the view needs them.
A common example is a UI that should show the name of a person. The model has
Person instances that are containing string variables for “forname” and “surname”. In the UI you are expecting this informations to be presented in a nice way. The viewmodel would take the person instance and concatenate the for- and surname to one single string that is provided as a property “name”. The view has a label that’s textProperty is bound to the name property of the viewModel.
The design pattern defines a strict top-down visibility for the components. The View knows the ViewModel. The ViewModel knows the Model but not the View. And the Model knows neither the View nor the ViewModel.
What is really cool about this design pattern is that the whole UI specific logic is only located in the viewmodel. Conditions like “Is the button x disabled or enabled?” are developed in the viewmodel. The view doesn’t know about this conditions. It only knows that there is a button and that it’s visibility property is bound to a boolean property in the viewmodel. The view doesn’t care about under which conditions this boolean property is true or false.
This enables you to unit-test your UI logic. The viewmodel is only a simple Java class. You don’t need to boot-up the whole application to perform difficult UI integration tests. JUnit is all you need.