ShowTable of Contents
The model container builder is probably one of the least used yet most valuable builders provided by WPF. This article explores how to design an application to take advantage of it. As the name suggests, this builder has the ability to contain other models within it and switch out those models dynamically. We can take advantage of this feature to build a series of screens that the user navigates through while keeping the models separate, as opposed to using the imported model builder which generates one monolithic super model.
We want to create a CRUD (create,read,update,delete) application for some contact information using the model container builder and some events. Each of the CRUD features will be implemented in its own model, and each will be executable on its own with a main action list. The model container will swap out each of these models based on events which are fired to indicate the next navigation page.
Sequence Diagram:
Events
The model container will dynamically swap out/in the appropriate model based on events fired and trapped(see above diagram). Events are declared in a separate model and imported into the controller, readItem, editItem and listItems models. By firing events instead of directly requesting a page we don't have to keep a reference to the page (by importing the model which contains the page). This helps to keep everything tidy.
ModelInitializationData
A key component to making this approach work is a special variable named
ModelInitializationData which is used to pass data from the model container to the child container. This can be observed in the event handlers' action list:
modelContainer.setModelName(DsixE/ModelContainer/readItem)
modelContainer.callInitializationAction(${Arguments/uid},true)
pageMC
The first line in the action list uses the LJO from the model container to tell it which model to load. The second line tells it what value to store in the
ModelInitializationData variable, in this case the unique id that identifies which record we're interested in reading.
controller Model:
The child model contains a declaration for
ModelInitializationData and uses that value in its main action list to retrieve data from the service consumer. The child model also contains buttons/links that will fire appropriate events telling the controller what to do next.
readItem Model:
The nice thing about this approach is that everything is kept isolated, each model can execute on its own based on whatever value is populated in the ModelInitializationData variable and several developers can work concurrently without stepping on each others code.