You use ViewModels (also called views) to define a perspective on your model information for a user interface, a REST API, or a report. This page is for people starting in MDriven Designer who need to decide what a view should show and whether it should be rooted or unrooted.
Contents
What a ViewModel is
A ViewModel describes a selected part of the information in your model. It does not replace the model classes, attributes, or associations; it presents information from them for a particular purpose.
For example, if your model has a Customer class with a name and related orders, you can create a Customer view that shows one customer, their name, and their orders. The same model information can be presented in another view for a different purpose, such as a list used to find a customer.
You can use ViewModels to:
- Define a user interface (UI).
- Describe the information available through a REST API.
- Describe the data available in a report.
Before defining a view, make sure the information it needs exists in your model. Define simple values as attributes and relationships between classes as associations.
Choose the ViewModel type
Every ViewModel must be typed to a class. You must also decide whether the view is rooted in an object of that class or unrooted.
| ViewModel type | What it starts with | Typical use | Example |
|---|---|---|---|
| Rooted | A specific instance of its typed class. | A document or detail screen that displays or edits one object. | A Customer view starts with one selected Customer and shows that customer's name and related orders. |
| Unrooted | No specific instance. The view finds information at type level. | A seeker or search view that helps a user find objects to open in a rooted view. | A Customer seeker finds Customer objects so the user can choose one and open its Customer view. |
Rooted ViewModels
A rooted ViewModel receives a specific object of the class it is typed to. Use one when the screen is about that object.
For example, type a view to Customer and root it in a Customer object. The view can then show the Customer's own attributes and information reached through its associations, such as the Customer's orders.
This is the usual choice for a document screen: the user is viewing or working with one known object.
Unrooted ViewModels
An unrooted ViewModel has no starting object. It must obtain its information on type level rather than from a supplied instance.
Use an unrooted view as a seeker when users need to find an object first. For example, create a Customer seeker that presents Customer objects; after the user identifies the required Customer, open a rooted Customer view for that object.
Start with AutoForm
Use the AutoForm technique when you need a quick ViewModel for exploring the current model. AutoForm can rapidly create ViewModels that let you browse the information available in the model.
AutoForm is useful early in development because it gives you a starting point for inspecting your classes and their related information. Treat the generated ViewModel as a starting point: choose the view type that matches the user task and refine the view for the information you want to present.
For example, use AutoForm to create views for your current classes, browse from a Customer to its related orders, and then decide which information belongs on a Customer document screen and which belongs in a Customer seeker.
Define views in a practical order
- Confirm that the required classes, attributes, and associations exist in the model.
- Create or generate a ViewModel with AutoForm.
- Set the ViewModel's type to the class whose information the view represents.
- Decide whether the view is rooted or unrooted.
- Use a rooted view for a known object, such as one Customer; use an unrooted view to find objects, such as a Customer seeker.
- Review the ViewModel to ensure that it presents the information needed for its purpose.
- Validate the model before you run it.
Connect views to user interaction
Views present information. User actions determine how users open and work with those views.
For example, a global action can bring up a Customer seeker. After a Customer is selected, another action can open the rooted Customer document view. Actions that are specific to one ViewModel are described in ViewModel actions.
Validate before prototyping
After you define your views, validate the model. The model must be coherent and free of errors before you start the Prototyper or deploy it. Validation runs automatically when you save the model, and you can also run it manually with the Validation button. See Verify.
When validation is clean, start the Prototyper to interact with the system and check that each seeker and document view supports the intended user task.