which can do everything you want to do with the application. So what would be the job of the UI?
The UI enables a user to interact with the model. In terms of the business model this corresponds to
- instantiating objects or
- finding objects that have been instantiated already,
- accessing their properties and
- calling their methods.
If it is the UI’s job to forward these functions to the user, it has to be able to do the following:
- instantiate objects,
- provide means to navigate their relationships,
- provide means to modify their relationships,
- keep track of object selections,
- display and edit object’s properties,
- provide means to call methods,
- capture and display the result of method calls.
“Provide means” in this context means to provide a visual presentation for the action and to translate input gestures into the necessary method calls on the object model.
In addition to that, there are some tasks that mainly concern the UI, not the object model:
- provide descriptions of itself (internationalized),
- provide context sensitive online help,
- translate user readable values into machine readable values and vice versa,
- provide validation feedback.
Ok, so much for the cooperation between business model and UI layer. However, there are some services that every application needs, independent from the actual business object model. These services include
- persistence of business objects,
- Notifying the business model of application lifetime events, i.e. startup and shutdown,
- persistence of application settings.
All of these functions are already present in .Net. Most of them are also available in WPF. It remains to be seen how to connect the two in the cases where the connection is not obvious.