MVVMS... A Better MVVM? Model-View-ViewModel-Services Explained

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
all right you asked for it you left comments and all of my architecture videos so we're going to talk about architecture yet again that's right we're talking about mvvm s that's right it's my architecture pattern that I've used for the past 15 years for my very first job all the way into the most recent app that I've deployed into the App Store I'm gonna break down exactly what mvbms is and why I think it's so important and help answer your questions along the way so let's get into it [Music] foreign [Music] I'm James and I'm back with another video this time talking about architecture because you had many many questions I just put out a video not too long ago about mvvm model view view model architecture which is all about architecting code specifically for doing data binding and it works really nice with things like xaml UI so if you're doing things with net Maui or uwp or win ui3 or avalonia or Uno or any of these platforms it's going to work super duper great because it has two-way data binding built in we talked a lot about what it looks like to put your code just in the code behind and then what it means to put your code in an mvvm architecture pattern that makes your code testable and makes your code decoupled and additionally it makes it really nice to do that cool data binding back and forth now many of you have questions though some people said what about the model and then some other people said what about the view model and then other people said what about the services well okay okay and a lot of people have questions like how smart should things be should the model be smart should the view model be smart should the services be smart like what should actually happen here and it's all good questions to be honest with you and I'm going to break down what my specific architecture pattern is that I've used for the last 15 years I started my career off working at Canon the camera company but I worked on big printers like this one here and different flow job management software uh over there and everything was interface-based we had interfaces for everything under the sun and I thought that was really great because it makes things really decoupled and really testable but while I like interfaces I don't like to go interface overload to be honest with you I like just some interfaces when necessary now mvvm s the S standing for services is the most important part of my architecture pattern that I use I didn't create it I didn't invent it I just add added an S to the end of mdvm and that's my services so I think the best part of demoing what this means and why I use it personally and why I think that you should look at this way of decoupling certain pieces of functionality away from other parts of your application as much or as little as you need to is in actually the monkey finder application for my.net Maui workshop and this is a app that I've built over the years and turned into a Maui workshop and over a hundred thousand people have watched my videos I'll put up right over there uh that's four hours long walking through the application but this architecture pattern and mvvms and using your services like I said I didn't invent it you can use it in any application type that you're using so if you're doing WPF or things like that you're good to go let's go ahead and get into it all right the very first thing we're going to see is the monkey finder application this application is relatively simple you say get monkeys it goes off to an internet service provider does a restful service call or reads from a file this monkey data and then you can tap on a monkey it navigates to said monkey and then you can also find closest using geolocation you can go ahead and open on the map and it opens it there now let's head into Visual Studio 2022 and take a look now the first thing that I want to talk about is just the xaml here so again this is using Straight mvvm architecture pattern we have my data type here which is giving just some intellisense to the um user interface and also doing compiled binding so if I do a typo or mess something up it'll let me know I have some standard commands here so when I pull the refresh that's going to go ahead and hit the get monkeys command there is the is refreshing there's a collection view with monkeys as the item source and then we simply bind up a whole bunch of different things like tap gesture recognizers image different labels inside of here with that monkey information so nothing too crazy here we go we have buttons we have activity indicators straight and vvm now if we pull out my solution and I zoom in over here we can see that I have m v v m and services okay so the service is unfortunately alphabetically doesn't align with exactly how I would like it but I do this here now I also do view instead of views instead of view models because I actually like it to say model view view model I'm just uh I don't know that's just me I just can't help myself uh I guess I could do something instead in front of services to make it go to the bottom uh but you know even there's other folders in between it now the first question many people ask was what about your models James you forgot about talking about models in mvvm okay well I kind of did but models should be very primitive in my personal opinion you can actually look at my monkey class here the monkey class doesn't know anything about anything really in general I think that these are simple objects that they're just used temporarily to hold data they really shouldn't know too much about anything maybe you override some comparison methods you override some two string Methods but an Ideal World in my purse personal opinion they shouldn't do anything one caveat to that I would say is if you are doing some certain things they they may for example hold some data such as you know I want to do a display name or I want to give you the first letter um you know and those might be things that aren't in the database or they might not be inside of the Json feed that's coming in but in general I think that these should be very very simple and if you look at a lot of my applications that are on my GitHub you're going to see that this is how I structure almost all my applications and my data objects they shouldn't be Computing stuff they shouldn't be doing very much they should just be sitting there they're models they're just around not doing much at all they may for example be have a database object type or you might decide that that database object type is separate from your model based if you're sharing that database model across apps now when it comes to view models those also should be relatively not that intelligent I think in my personal opinion I would say that this here is an example of something that's in the middle of nvvms in my personal opinion uh but uh when it comes to the view models I don't really think they should know too much of where the data is coming from they shouldn't be querying a service they shouldn't be querying a database they really shouldn't be doing much so this is my base example here inside of my view model and what we can see in the Constructor is it takes in three different pieces of information a monkey service eye connectivity and igeolocation now some may argue here that I might have my own connectivity service and my own geolocation service that take in these interfaces but I do think that in general here this is a pretty decent practice based on what those interfaces are giving you if you do have and do need to do a lot of computation around connectivity or geolocation you might put those in their own separate class in their own separate service so if we look specifically at the get monkeys command this is a great example here the first thing I do is I use that interface and I check if there's connectivity and here I just you know check if it's the internet does not equal internet and pop up a display again this could be a its own service right it could be uh you know a weight connectivity dot check internet for example and we remove this decoupling of of checking for connectivity here because we might want to reuse that logic later on depends how advanced your app is but the most important about the actual services and when I look at a service I think about making a restful service call hitting a database making authentication Service things like that we simply say monkey service get monkeys notice here that the view model is not tapping into a database it's not tapping into a restful service call it's not tapping in to reading information from a file and deserializing it because we want to decouple that completely to make that component really testable and reusable across different parts of the application the only thing that the view model really cares about is that list of monkeys that it's going to data bind up and specifically any properties that is going to also data bind up to see if it's refreshing or it is busy and that's kind of it down here we can see this is a good example of maybe this should have been you know a a service a geolocation service where we're getting last known location or getting the location async so those are kind of a mixed bag versus like mvvms light in a way if I was to do it that way but if we look at the service and introducing this pattern there is one service inside of here which is the monkey service now what I like about this monkey service is that we're able to put it behind an interface if we wanted to totally up to you if you want that to be completely completely decoupled and you want it to be an interface you can do that like my iGo location and eye connectivity that's coming in from Maui but here what we're going to note is that the monkey service itself is going to be in charge of the HTTP client if this was a database for the monkeys it would be in charge of accessing that database this could be the database for the entire app or maybe just for the monkeys it's up to you on that granularity level and that connection that you have here this is the code that we do not want into our view models I think that view models should be light to medium so they shouldn't be making restful service calls they shouldn't be handling status codes they shouldn't be deserializing information whether it's from the Internet or if it's from a Json file or from a database now what's nice about this is that at any point I can come in I could easily test this application and this logic and then my view model over here knows nothing about it if I want to now add another method called get monkey and pass an ID into other things like that it's completely removed completely detached 100 so we look at the model super duper simple the lightest of lightest weight really knows nothing about anything view models here ideally as we can see coming in from the Constructor which is using the built-in dependency injection this is going to be very very minimal it doesn't know about the connectivity it doesn't know about the geolocation it doesn't know about the monkey service it just knows what it can call on it what's being exposed then we have the service the thing that's doing the bulk of the work that is independent from the user interface and independent from the state of the user interface completely so I think these are great examples of like I said databases reading from file making restful service calls and those can be as granular or non-granular as you want inside of your application and the thing that I love about this is that it all works very very nice with the built-in dependency Injection Service especially if we're using let's say in Dona Maui for example you're using shell that'll be injected into the pages into the view models into the services across the board but there we go that is my mvvm S architecture pattern what do you think do you have more questions did I not answer anything do I need to make another video on architecture let me know in the comments below I do read all of them I try to answer as many of as many as I can below uh down there of course I really appreciate everyone's been hanging out on the channel leaving comments leaving those likes and of course subscribing and tapping that notification Bell so you get subscribed and you get notifications every single time I put out a video you cannot hit that notification Bell and it'll just come up in your subscriptions feed I do that for some channels based on what you want but I put out videos almost every single week here on my YouTube and I also live stream so those notifications do help there as well let me know if you have any more architecture patterns I will continue to do mvvm videos until the day I die I think because I love it or until something replaces it but for me I love it and I love my architecture pattern as I said I've used it in almost every single application that I've ever built you can take a look especially at my uh let's my other applications on my GitHub the island tracker application is a great example um I think also the podcast application also very similar and that one even Architects out more of those Individual Services uh so you can see that there now this has just been one in my many many series of mvvm and architecture videos I'll put links below to all the other videos and of course that four hour long video all about getting started and building your first applications with DOT net Maui I hope that you enjoyed this video if I did if you did thumbs up it super helps out goes into that YouTube algorithm of goodness really appreciate it hope you have the most amazing day in your entire life if you have any questions let me know below until next time thanks for watching [Music] thank you foreign [Music]
Info
Channel: James Montemagno
Views: 26,278
Rating: undefined out of 5
Keywords: mvvm, xaml, model view view model, .net maui, dotnet maui, wpf, avalonia, avalonia ui, .net maui architecture, .net maui mvvm, .net maui data binding, uno platform, mvvm tutorial, xaml binding tutorial, unit testing, .net, .net maui tutorial, c#, c# mvvm viewmodel, mvvm pattern, mvvm viewmodel tutorial, c# viewmodel tutorial, c# mvvm pattern, wpf mvvm, c# mvvm framework, mvvm c#, mvvm design pattern, c# tutorial, how to use mvvm
Id: ve0DFu-arD8
Channel Id: undefined
Length: 14min 23sec (863 seconds)
Published: Thu Jul 07 2022
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.