What is MVVM (Model-View-ViewModel) Pattern?

so what is this mvvm all about mvvm stands for model view viewmodel and it's an architectural pattern for implementing user interfaces it consists of three moving parts model which represents the business objects that encapsulate the data and behavior of application domain so if you're building an application for finding flights your application domain model includes classes like flight location time frame and so on the second moving part is the view which is what the user sees in xamarin world that means a page and the third moving part is the view model which is a model specifically designed for the view so it's a class with properties that represent the state of the view and methods that implement the logic behind the view for example imagine we have a page with a list and a button when the user clicks this button a new item is added in the list if you want to create a view model for this view we need a class with a property like items which is an observable collection so this property represents the state of the view the state of the page this class should also have a method like add and this method is called when we click the Add button so pretty simple it's no magic now you might ask but maash what you're saying sounds like the code behind because in the code behind we have this observable collection and this add method in terms of an event handler that is linked to the bun well not really code behind is not view model as I will show you in the next lecture code behind is tightly coupled to summary and this tight coupling makes it hard to unit test this class so by applying MVVM pattern we basically take all the code in the code behind put it in a view model class and modify it slightly so it has no coupling or minimal coupling to Samri and this way we get what we call a plain old CLR object or poco that's a class that has simple properties and methods and we can easily unit test this class so as you might guess you should use mvvm only if you want to unit test your applications presentation logic if you don't do unit testing you really don't need nvvm and it's actually better to write all the code in the code behind because as you will see in this section mvvm involves some challenges and sometimes you have to write a bit more code but you do this for a reason for decoupling your applications code from xamarin so you can test it if you're not going to write unit tests for your application you would just waste your time implementing mvvm let me tell you something no end-user cares how many design or architectural patterns you have used in your code users want applications that work applications that are user friendly reliable and fast they don't care about nvvm nobody is going to give you a price for using a mvvm so here's my pragmatic suggestion if your building is small or even medium sized an application and you don't plan on writing unit tests for your application it's perfectly fine to write all the code in the code behind you don't need a mvvm but as your application grows larger you would really benefit from unit testing and that's when you start refactoring your code to make it unit testable so don't start with mvvm right from the get-go you would increase complexity without gaining anything now just one thing even if you're not familiar with unit testing I want you to watch this section thoroughly because the concepts I'm going to cover will help you have a better understanding of software design I'm gonna talk about interfaces dependencies loose coupling and so on so watch all the videos and if some of them are challenging and beyond your level that's perfectly fine I don't expect you to walk away and be an mvvm expert but at least I want you to hear the concept I'm going to talk about in this section because it's very likely that you're going to hear these concepts again in the future so if you have a background and you heard it once before it's going to be much easier in the future with all that let's get started hi guys Marsh here I hope you're having a fantastic day or night wherever you are in the world this tutorial you've been watching is actually part of my summer informs course where you will learn everything about building cross-platform mobile apps with sushar in that course we have a more in-depth discussion of the MVVM pattern I'm gonna show you a sample application without the MVVM pattern and then explain why we need the MVVM pattern there and how to implement it in case you're interested to enroll in the full course I've put the link for you in the video description and if not that's perfectly fine have a great day all right to see mvvm in action I have built a very simple application and if you want to code along with me download the zip file I have attached to this lecture so first let's see what this application does here we have an Add button on the toolbar when we click that it creates a playlist object and add it to our list let's try a few times note that the title of the page is dynamically updated and here we have for playlist also below each playlist we have this detail label which determines if we have marked this playlist as favorite or not now if I tap on one of these playlists favorite becomes true and the color of playlist changes to pink if I tap it again it goes back to its previous state so very simple application it exhibits a few patterns here we have a list we have selection of items we have adding an item to a list and we have obtaining the page title and here is the source code for this project so we have models folder where we have our playlist class and we also have views with two pages playlist detail page and playlists page now as we work through this section we'll explore each of these files in detail now let's take a quick look at the code behind for our main page which is playlists page so here we have an observable collection which is used as the item source for our ListView very similar to what you have seen before no magic note that we are setting the item source in on appearing method below that we have to event handlers one is on add playlist and the other is on playlist selector again the code you see here is very very simple and you have seen several examples similar days throughout the course so I'm not going to explain this line by line but I want to point out a few reasons why this class is not unit testable the first problem is this on appearing method so this method as you know is called automatically by the framework when the page appears now in this method we are sending the item source for the ListView the problem with this method is that we cannot call it from our unit tests because it's protected and I cannot change this to public either because here we are overriding on appearing method that is defined in the base class content page so I cannot call this in a unit test and assert that the itemssource property of ListView is initialized now there is a hack around this we can potentially extract this logic into a public method that we can call from our unit tests but that's really a hack it's not the proper way the unit test this code so we have to revert this back to protected another problem is this ListView object itself as you know this is a private field in this class same applies to any other controls that we have in ours MO and we give them an X name we'll get a private field in this class now if you're directly working with these controls and the code-behind we cannot write unit tests to make assertions about the state of these private fields again we have to jump through the hoops we have to expose them as public properties and this is really messy let's look at another example look at these two event handlers again both of these are private methods if you want to call them from the outside we have to make them public no that's not the end of the world but imagine we had a call to display alert here and ask the user to confirm something now what is the problem here the problem is that in our unit tests we don't have a confirmation box so in a nutshell the problem with this code is that it's tightly coupled to xamarin if you want to unit test this the first step is to extract as much code as possible into a separate class that we call a view model and this view model should be decoupled from xamarin or any other presentation frameworks and this way we can easily unit test this because this view model is going to be what we call a plain old CLR object or poco it's a simple class with a few simple properties and methods it doesn't have event handlers like these private methods here it doesn't have any references to objects like select an item changed event args and so on so starting from the next lecture we're going to refactor this code step by step and extract as much logic as possible into a view model ideally this code behind should be empty but that's an ideal point and may not always happen as you will see later in this section so now let's start refactoring this code

Channel: Programming with Mosh

Views: 318,991

Keywords: mvvm, c#, xamarin, xamarin forms, unit testing, design patterns, code with mosh, programming with mosh

Id: fo6rvTP9kkc

Length: 10min 7sec (607 seconds)

Published: Tue Nov 14 2017