Hey guys,
I am struggling with the mvvm concept. Is anyone able to provide me with links to resources that could help? Preferably books or github projects that I could read through?
What I’m struggling with most is where to put thr buisness logic, currently it’s in my viewmodel. But it’s getting very bloated…. Please help…… š
Your view models job is to help present the data. The business logic should not be in the view model. When a view model is created, it should get data from a service layer(the business logic layer). This layer can be another library or just a service class within the same project. The service layers job is to transmit entities between the presentation layer(your view models) to your data access layer(another class or service that can take a model and put it into a database or serialize it to an API). Once the view model gets the data, it places the fields into the properties of the view model(the properties our bond to the view). If the user is allowed to manipulate the data, once they do, you map those view model properties back to entity that your service layer can understand in order to save your data. Hopefully this helps a little. If you want some actual examples, pm me and I’ll be happy to help.
Business logic must be in your domain. Viewmodel controls the UX. 2 separate concepts. Although in some cases some business related ideas do creep into the UX and that is not wrong. Make sure to refactor that out into separate classes and then use composition to make the viewmodel use that if required.
All business logic should be in the model, and the model should be 100% independent of the view and the view model.
The view model is essentially a mapper between the view and the model. If the model has a list of employees, the view could have a page with some input fields that can be used to edit an employee. When a user opens that edit page, the view binds to some properties of the viewmodel. Whenever the user changes a property, that change is caught by the viewmodel which then updates the model.
The model should expose a number of methods that the viewmodel can use to fetch and/or update data for the view to bind to.
Say you wanted to be able to change the address an employee works at. Your model project would expose a method or property EmploymentAddress. The viewmodel would get that property and map it to something the view can bind to. The view them binds to that mapped object in the viewmodel. When the user then changes the address in the view, that triggers an event in the viewmodel which in turn does something to the actual model.
This way the viewmodel doesn’t reference the view, and the model is independent of both the view and viewmodel.
So in this instance, would I keep the i commands in the viewmodel
ViewModel should only contain presentation logic. e.g.
StockLevel is < 50 display as amber
StockLevel is < 10 display as red
I think that is the point of the view model. It can be bloated as it holds the logic. Might you be able to refactor? Then again Iām a noob searching MVVM info as well. Trying to find all of the key points needed to make it work. Like using ICommand
C# devs
null reference exceptions