Models are where the majority of business logic is stored in the mobile app, it retrieves the data, reads and populates the properties in the model. The model also holds the state of that particular part of the application. In keeping with the silo approach, models should only talk to the repositories necessary and be called upon from the ViewModel. Talking between models can be done via the Messenger service if needed. If you have shared business logic between models, add an optional service layer.
Models
Models hold state and business logic for the appropriate object. Lets look at an example of the LoginModel.cs that is used for the Login page of the mobile app. The model contains 3 basic things
- Constructor Injected Service or Repository
- Properties that raises the INotifyPropertyChanged event
- Methods that contain business logic to be performed upon an event
The Model is called directly from the ViewModel. The ViewModel has the Model injected into it. There are two approaches in keeping instances of the Model, you can create on for each ViewModel or share it between ViewModels and this can all be done via the dependency injection. If you wish to create a new instance on each call you can do this:
At this point you are also mostly at the limit of what SimpleIoc is capable of and you might want to switch to a more advanced package if your needs require it.
Each property you want accessible to the View will need to be made public and have the INotifiyPropertyChanged event raised. MVVMLight has a nice wrapper here where you can use the RaisePropertyChanged method as shown in the LoginModel.cs
Finally you can see an Authenticate Method. It doesn’t require any incoming parameters because it is reading off the state in the Model. It uses this to call upon the Service or Repository to authenticate the details and provide feedback upon its result. The ViewModel will deal with the showing of dialog’s and presenting user feedback based upon its result.
Service Layer
The Service Layer can be considered a shared business logic layer between models. The service layer can have constructor injected repositories and is called directly by the model to perform actions upon the repository or just within itself.
AutoMapper
AutoMapper is a great tool to quickly map back properties from DTO’s in the repository layer to the model. I would recommend using AutoMapper to take DTO’s back and fill in the properties in the model. You can map back to an already existing object by specifying the destination, rather than letting it create a new instance.
There is saying of “Friends don’t let friends use AutoMapper”. But I have to disagree with this one. The common issue faced with AutoMapper is if you change properties in one model you won’t get a compile error and then be faced with introducing bugs into your code when model’s don’t match. The simple solution for that is Unit Tests and AutoMapper came up with an out of the box solution specifically for this use case called Configuration Validation.
5 Common Pitfalls In Enterprise Mobile Development
<< Separate Navigation Stacks (Day 5) || Messenger Service (Day 7) >>
14 Days To Building An Enterprise Quality Xamarin Forms App
Cross platform mobile developer who loves delving deep into frameworks and solving problems.