100 Days of Code is done. I may not be coding every day (last weekend we went to Moab and spend our days in Arches National Park and I didn't code) but I am still taking time to learn things. I am nearing the end of a Xamarin.Forms class on Udemy taught by Moshfegh Hamedani. I have one more activity left and then "Beyond the Basics" section to go. Then I will be a great Xamarin.Forms developer, right?
Well, I will have more tools to help me at least do some development in Xamarin.Forms. Today I did the section on MVVM (Model-View-View Model) pattern. I knew that using the code behind, like we did in all the examples, may not be the best way to code in XAML. We use MVVM in some of our applications at work and I thought this section would be great to learn for my own project and also so I can better understand what we are doing at work.
Well, I will have more tools to help me at least do some development in Xamarin.Forms. Today I did the section on MVVM (Model-View-View Model) pattern. I knew that using the code behind, like we did in all the examples, may not be the best way to code in XAML. We use MVVM in some of our applications at work and I thought this section would be great to learn for my own project and also so I can better understand what we are doing at work.
We hear that teaching is the best way to learn. And by we, I mean that I have heard that many times and again today in a video post on YouTube channel called Top 8 developer habits: Teaching - Fun Fun Function. Watching that today I thought, why not, let's blog about MVVM to help make sure I really understand what I learned.
What is the best way to describe MVVM? Well, it helps separate concerns of the front end and the back-end logic. This will ensure that the front end doesn't need to know the logic behind the data and the back end get's to do all the calculations and only give the data when it is asked for. Your view just needs to know what to pull and the model will just store the content.
Model: The model is a domain model that has both the behavior and the data. When you enter new data to be stored, the model will handle any transformations to new data and then store the data.
View: This is what the end user sees, so make it pretty. It isn't going to do much else.
View-Model: This is a layer of abstraction between the model and the views. The view model will make the calls to the model and send the data to the view to be shown. It also works the other way. It can take that data from the View and send it to the model to be stored. It will also know what to do when you change a setting or click a button (that doesn't change/add data to the model) in the View. It let's the model just know what to do with the data and the view to just continue looking pretty.
Quick lovely drawing that you probably won't be able to read:
What is the best way to describe MVVM? Well, it helps separate concerns of the front end and the back-end logic. This will ensure that the front end doesn't need to know the logic behind the data and the back end get's to do all the calculations and only give the data when it is asked for. Your view just needs to know what to pull and the model will just store the content.
Model: The model is a domain model that has both the behavior and the data. When you enter new data to be stored, the model will handle any transformations to new data and then store the data.
View: This is what the end user sees, so make it pretty. It isn't going to do much else.
View-Model: This is a layer of abstraction between the model and the views. The view model will make the calls to the model and send the data to the view to be shown. It also works the other way. It can take that data from the View and send it to the model to be stored. It will also know what to do when you change a setting or click a button (that doesn't change/add data to the model) in the View. It let's the model just know what to do with the data and the view to just continue looking pretty.
Quick lovely drawing that you probably won't be able to read:
Ok, why do you want to use MVVM? From what I have heard (I still need to do this on my own) it makes your code more testable. If you are using Xamarin.Forms and do all the code in the code behind, you can't test it. It is too tightly coupled with the XAML code and your tests won't be able to see what is happening in the UX layer. MVVM will also keep a separation of powers.
What could be a downside of MVVM? The amount of time it takes to implement MVVM may be overkill when you have a simple application or you never plan on doing testing (pretty sure this is unit tests, you will always want to have some sort of testing before you release to the wild). What is the size of the application it would be overkill? Good question, maybe a small to medium application would be fine using just code behind or using a model and view alone. Large projects you will probably want to use some framework that will allow for better testing.
That is probably an over simplification of the MVVM model, I think I am going to put some time on my team leads calendar tomorrow to discuss it with him and make sure I have it correct, isn't Ryan lucky?
"All great achievements require time." - Maya Angelou
What could be a downside of MVVM? The amount of time it takes to implement MVVM may be overkill when you have a simple application or you never plan on doing testing (pretty sure this is unit tests, you will always want to have some sort of testing before you release to the wild). What is the size of the application it would be overkill? Good question, maybe a small to medium application would be fine using just code behind or using a model and view alone. Large projects you will probably want to use some framework that will allow for better testing.
That is probably an over simplification of the MVVM model, I think I am going to put some time on my team leads calendar tomorrow to discuss it with him and make sure I have it correct, isn't Ryan lucky?
"All great achievements require time." - Maya Angelou
2 comments:
I think you've got it down pretty well - I've always been confused at how much logic should be in the model vs. viewmodel, one guideline I've tried to use is to make the model as dumb as possible (it stores state, not behavior) and let the ViewModel drive behavior (user clicked a button, or an application event occurred) and translates that behavior into data for the model.
I do love the way you describe the view - it just sits there and looks pretty :)
Thank you, Peter! I appreciate your feedback. It makes sense to have more work on the ViewModel instead of the model doing much behavior.
Post a Comment