ViewModel Object Models
View Model classes act as a layer of separation from the Object Models. Here we place properties and methods that are unique to the UI or are transitory in nature, meaning they have meaning that is not directly used in the UI, but are only applicable to related UI properties or UI functions. Properties such as ‘IsNew’ or ‘IsDirty’ are two that immediately spring to mind when thinking about these types of properties. They are used outside of the UI, but are not retained in with the user data in a persisted state.
Class Diagrams
Inheritance paths and aggregation is greatly simplified with the help of polymorphism.
Sequence Diagram
Sequence Diagrams provide great insight into the flow of data in an application. Since this application employs data binding, there’s not a lot to visualize with sequence diagrams except for the processes that are triggered by user entry.
Here we see the basic path that takes place when either the Bank Accounts or Budget Categories page loads.
The DataService class serves as a broker between the View and the ViewModel. Inside the DataService class, we instantiate the main ViewModels for the screens: BudgetCategoriesViewModel and BankAccountsViewModel. Each has their own internal methods used to load and populate values and then is returned to the View by the DataService. Once it’s finished loading the data, it is set as the BindingContext for the appropriate ListView in the ContentPage XAML file.
For creating, removing and modifying objects, the UI Event Handlers are configured to respond to button clicks in the UI that trigger CRUD operations on the BindingContext/ViewModel instance for that page. The ViewModel class contains methods for persisting changes. These methods rely on the UnitOfWork class to manage calls to the Repository level to write the changes to the Sqlite database.
The UI and ViewModel use Data Binding to notify each other of changes. The ViewModel classes use INotifyPropertyChanged and ObservableCollection objects to facilitate these updates. When necessary, events are configured in child ViewModel classes to notify the parent of changes. Removal of event handlers occur when a child object is removed, or when the parent object is disposed.