Great tutorial! I used to have everything in my ViewModel, which is quite large for some. Good time for me to implement what I have learned here. Thanks!
Hi Sean, thank you for sharing your knowlege. I'm a newB but I love your way of teaching and your architecture seem clear to me. Keep up please. Respect!
I always like to see new ways to handle problems. Thank you for your time and work to on your awesome videos. 😉 But in most cases I will stay with command handling in the vm. If the vm is getting to big and complex. I would try to split it up in smaller pieces.
Thanks JochenG, I think your approach to this is great! For simple scenarios, using a relay/delegate is soo much easier. It's a fair argument that using class commands and CreateCommand all the time could be a case of YAGNI, especially if the command implementation isn't reused and the view model will never need a different command. On second thought, even if CreateCommand is overkill, I still think class commands make unit testing more enjoyable. Regardless, thanks for the positive feedback JochenG!
Thanks pleasecheckmyid, glad this was helpful and I agree! It's super flexible and is something I almost always use in my own apps. It can be kind of a pain to integrate with dependency injection, but I've found a really clean approach that I'll show off in a future video.
Quiero programar con esa fluidez T_T Explicaste de manera eficiente sólida Agradecido con tu contenido. ¿Recomiendas algún libro para profundizar los temas que trataste? Se me hace un lío aplicar todos los conceptos. Soy nuevo en el tema
@@SingletonSean Just a request: Can you do a MVVM framework, like MvvmCross, tutorial in the near future? Would love to simplify the MVVM in my applicaiton
I think extracting command call back methods might be good for low or mid-level apps but when the apps grow big enough this approach might just add more complexity to the project and make it harder to maintain.
Thanks for the feedback Cyril! Interesting, I actually think the opposite. In large applications I've dealt with, some view models grew to 5000+ lines due to implementing everything as callback commands. By the end of the day, my index finger was always sore from scrolling, hahaha. I suppose it was nice knowing everything I needed was in that single file, but that also meant everything was tightly coupled together and more rigid. Regardless, this was a very subjective video, and there isn't necessarily a right/wrong answer. The right answer is building an application that meets it's requirements and is maintainable/extendable.
@@SingletonSean Actually if a class (view model or whatever) reaches 5000 lines or more it surely violates the SRP (single responsibility principle), in that case, we need to divide the tasks into services to make them smaller and cleaner, maybe it's just my opinion but I don't let my view models grow that big, cause it makes them hard to maintain.
How the F*ck I have not seen this video, It took me too long to understand WPF and this right here is probably the best Layman explanation I've seen. Only masters can explain to a toddler. I am so f*cking upset for wasting my time learning from other mofos. Sh*t I could've save a lot of time. Thank you Very much.
I was totally skeptical of this approach until I actually tried it, and now I am a huge fan. I felt like the file clutter would be annoying, but I've found that it is actually easier to maintain, test, debug, and to replace components that need updated functionality without being forced to replace existing code. I've already started converting one of my main projects and will consider this my go-to from now on. One note is that you can have the command requery the CanExecute method by using CommandManager .RequerySuggested public event EventHandler CanExecuteChanged { add { CommandManager.RequerySuggested += value; } remove { CommandManager.RequerySuggested -= value; } } It seems to work consistently in most situations except for CollectionChanged, in my experience.
That's awesome to hear joshman! I feel the same way, the flexibility is great. RequerySuggested is a solid solution too. The only drawback is that I noticed it's like .25 seconds slower compared to manually raising CanExecuteChanged (at least last time I used it I noticed a delay, perhaps it's better now or there was something else causing the delay). Anyways, the mini delay isn't really a big deal, hahaha. Thanks for the feedback joshman!
@@SingletonSean in my latest projects I haven't noticed any delay so hopefully they have solved that. Of course I also use the PropertyChanged.Fody package to automatically weave my PropertyChanged calls, so it may be helping with that. Sort of a double-dip maybe...lol
simple? The more mvvm videos i watch the more i think I should go back to winforms. I started to love working with wpf until I started trying to go the mvvm route, so much more code needed, a small project quickly become larger. Great videos and content. Any chance of doing windows forms videos?
I think you have a valid point Hawkeye. It's "simple" from the point that each layer is thin and easy to understand. However, it's certainly complex from the point that there are now more layers to deal with. I somewhat miss the simplicity of the winforms days, hahaha. I probably won't be returning to winforms on this channel. If anything, I'll be moving forward with MAUI and some WPF. Regardless, thank you for the support and constructive feedback!
I've taken a small look at it. My only concern is that it heavily uses Reactive Extensions, so I'm considering doing a tutorial on those too. I remember when I was ramping up on RX in C#, I had trouble finding good tutorials. I think RX didn't 100% click for me until I started using AngularJS. Regardless, ReactiveUI still looks fun!
Great question Dżaro! You will need to register the view models using factory functions so that you can pass in this specific CreateCommand that you want. It's a bit quirky, so perhaps I will make a video showing the approach I've grown to use.
And now we have passed the point where the abstractions are not adding anything. You are just smearing the business logic allover the code base. (see fizzbuzz corporate) The view model is there to present the view with a "view" of the model that is can "bind to". Buy and calculate price is part of the model and as there should be a model with a proper API that is view agnostic and do not concern itself with what view that is "binding" to it. One model -> Multiple View Models (One for WPF and one REST API) -> multiple views and the businesses logic SHALL be in the model and not smeared all over the different view models.
Thanks for the feedback MarcBot, you have definitely provided the most criticism in my videos lately. I agree, a view model is a model for the view. This demo application is focusing on view models, so the model is pretty much non-existent. I would definitely recommend creating a rich model rather than storing the business logic directly in commands. This is especially important in cases where the business logic needs to be reused in something like an API, as you suggested. In fact, perhaps I was misinterpreting the tone of your comment and taking it as a criticism. However, it turns out we actually agree on everything. Thanks for supporting the channel MarcBot!
@@SingletonSean Tone is hard to convey over RUclips comments, and responding on you phone makes it even harder. My intent was to be helpful. Will add more emojis to make it more clear. I recommend your videos to my teams WPF developers as you give a very good foundation in WPF.
Haha definitely, all good MarcBot! I like hearing peoples critiques of stuff like this, especially since the concepts in this video are extremely subjective.
When I did this in my work, a colleague that is our boss told me that he couldn't find any information anywhere about this pattern and made me put the commands back in the viewmodel. He even treat me like a stupid for doing this. This guy is an arrogant because he programs since he is 8 years old and in many languages and likes to humiliate persons. He said to me commands have to be inside the viewmodel.
I'm sorry this happened to you! This is an opinionated topic, so I suppose the team would have to agree on which approach to use. Commands in the view model are fine, but I still think there are situations where class commands thrive. It's a shame your boss will not get to experience class commands! 😄
Still way too complicated. You want to create 100 classes of Commands if your ViewModel has 100 functions? That sounds even more scary to maintain than just write the logic into the view model.
Hey Gnome, solid point. I still think relay/callback commands are appropriate in some cases, such as when the command is simple/only interacts with view model properties, or when reusability is not a concern. However, I'd be more concerned if I had a view model with 100 functions.
Great tutorial! I used to have everything in my ViewModel, which is quite large for some.
Good time for me to implement what I have learned here.
Thanks!
Glad this was helpful Michael!
Hi Sean, thank you for sharing your knowlege. I'm a newB but I love your way of teaching and your architecture seem clear to me. Keep up please. Respect!
Thanks jean-francois! Glad this is helpful, and more on the way of course. Thanks for supporting the channel!
I always like to see new ways to handle problems. Thank you for your time and work to on your awesome videos. 😉
But in most cases I will stay with command handling in the vm.
If the vm is getting to big and complex. I would try to split it up in smaller pieces.
Thanks JochenG, I think your approach to this is great! For simple scenarios, using a relay/delegate is soo much easier. It's a fair argument that using class commands and CreateCommand all the time could be a case of YAGNI, especially if the command implementation isn't reused and the view model will never need a different command.
On second thought, even if CreateCommand is overkill, I still think class commands make unit testing more enjoyable. Regardless, thanks for the positive feedback JochenG!
It's always important to have the right tool for the job.
I hope, have this in my mind if I need it the next time 😁
Been wondering about better options than instantiating commands in the VM if flexibility is needed so this is great! Thank you, as always.
Thanks pleasecheckmyid, glad this was helpful and I agree! It's super flexible and is something I almost always use in my own apps. It can be kind of a pain to integrate with dependency injection, but I've found a really clean approach that I'll show off in a future video.
Hi Sean, i've got a question please,
why dont you just pass into the vm's constructor the commands itself and instead you wrap it with delegate?
Thanks for the tutorial, it's really helpful and I like the video's structure a lot, keep it up! :)
Great video! As always!
Quiero programar con esa fluidez T_T
Explicaste de manera eficiente sólida
Agradecido con tu contenido. ¿Recomiendas algún libro para profundizar los temas que trataste?
Se me hace un lío aplicar todos los conceptos. Soy nuevo en el tema
You're a wizard. I'm a huge fan
Thanks for the magical comment, Robin!
@@SingletonSean Just a request: Can you do a MVVM framework, like MvvmCross, tutorial in the near future? Would love to simplify the MVVM in my applicaiton
Thanks. Super helpful.
Awesome stuff! I wish I had that earlier and I'm glad I have it now.
Glad this was helpful a k!
I think extracting command call back methods might be good for low or mid-level apps but when the apps grow big enough this approach might just add more complexity to the project and make it harder to maintain.
Thanks for the feedback Cyril! Interesting, I actually think the opposite. In large applications I've dealt with, some view models grew to 5000+ lines due to implementing everything as callback commands. By the end of the day, my index finger was always sore from scrolling, hahaha. I suppose it was nice knowing everything I needed was in that single file, but that also meant everything was tightly coupled together and more rigid.
Regardless, this was a very subjective video, and there isn't necessarily a right/wrong answer. The right answer is building an application that meets it's requirements and is maintainable/extendable.
@@SingletonSean Actually if a class (view model or whatever) reaches 5000 lines or more it surely violates the SRP (single responsibility principle), in that case, we need to divide the tasks into services to make them smaller and cleaner, maybe it's just my opinion but I don't let my view models grow that big, cause it makes them hard to maintain.
How the F*ck I have not seen this video, It took me too long to understand WPF and this right here is probably the best Layman explanation I've seen. Only masters can explain to a toddler.
I am so f*cking upset for wasting my time learning from other mofos. Sh*t I could've save a lot of time. Thank you Very much.
Hahah, glad this was helpful Exogen!!
I was totally skeptical of this approach until I actually tried it, and now I am a huge fan. I felt like the file clutter would be annoying, but I've found that it is actually easier to maintain, test, debug, and to replace components that need updated functionality without being forced to replace existing code. I've already started converting one of my main projects and will consider this my go-to from now on.
One note is that you can have the command requery the CanExecute method by using CommandManager .RequerySuggested
public event EventHandler CanExecuteChanged
{
add { CommandManager.RequerySuggested += value; }
remove { CommandManager.RequerySuggested -= value; }
}
It seems to work consistently in most situations except for CollectionChanged, in my experience.
That's awesome to hear joshman! I feel the same way, the flexibility is great. RequerySuggested is a solid solution too. The only drawback is that I noticed it's like .25 seconds slower compared to manually raising CanExecuteChanged (at least last time I used it I noticed a delay, perhaps it's better now or there was something else causing the delay). Anyways, the mini delay isn't really a big deal, hahaha. Thanks for the feedback joshman!
@@SingletonSean in my latest projects I haven't noticed any delay so hopefully they have solved that. Of course I also use the PropertyChanged.Fody package to automatically weave my PropertyChanged calls, so it may be helping with that. Sort of a double-dip maybe...lol
Thanks, good stuff!
Good way, Thank you.
Thank you for the nice video 📹
Thanks for supporting the channel Joachim, as always!
simple? The more mvvm videos i watch the more i think I should go back to winforms. I started to love working with wpf until I started trying to go the mvvm route, so much more code needed, a small project quickly become larger.
Great videos and content. Any chance of doing windows forms videos?
I think you have a valid point Hawkeye. It's "simple" from the point that each layer is thin and easy to understand. However, it's certainly complex from the point that there are now more layers to deal with.
I somewhat miss the simplicity of the winforms days, hahaha. I probably won't be returning to winforms on this channel. If anything, I'll be moving forward with MAUI and some WPF. Regardless, thank you for the support and constructive feedback!
Hello there, how is your progress looking into ReactiveUI?
I've taken a small look at it. My only concern is that it heavily uses Reactive Extensions, so I'm considering doing a tutorial on those too. I remember when I was ramping up on RX in C#, I had trouble finding good tutorials. I think RX didn't 100% click for me until I started using AngularJS. Regardless, ReactiveUI still looks fun!
How add CreateCommand to dependency injection?
Great question Dżaro! You will need to register the view models using factory functions so that you can pass in this specific CreateCommand that you want. It's a bit quirky, so perhaps I will make a video showing the approach I've grown to use.
And now we have passed the point where the abstractions are not adding anything. You are just smearing the business logic allover the code base. (see fizzbuzz corporate)
The view model is there to present the view with a "view" of the model that is can "bind to".
Buy and calculate price is part of the model and as there should be a model with a proper API that is view agnostic and do not concern itself with what view that is "binding" to it.
One model -> Multiple View Models (One for WPF and one REST API) -> multiple views and the businesses logic SHALL be in the model and not smeared all over the different view models.
Thanks for the feedback MarcBot, you have definitely provided the most criticism in my videos lately.
I agree, a view model is a model for the view. This demo application is focusing on view models, so the model is pretty much non-existent. I would definitely recommend creating a rich model rather than storing the business logic directly in commands. This is especially important in cases where the business logic needs to be reused in something like an API, as you suggested.
In fact, perhaps I was misinterpreting the tone of your comment and taking it as a criticism. However, it turns out we actually agree on everything. Thanks for supporting the channel MarcBot!
@@SingletonSean Tone is hard to convey over RUclips comments, and responding on you phone makes it even harder.
My intent was to be helpful.
Will add more emojis to make it more clear.
I recommend your videos to my teams WPF developers as you give a very good foundation in WPF.
Haha definitely, all good MarcBot! I like hearing peoples critiques of stuff like this, especially since the concepts in this video are extremely subjective.
When I did this in my work, a colleague that is our boss told me that he couldn't find any information anywhere about this pattern and made me put the commands back in the viewmodel. He even treat me like a stupid for doing this. This guy is an arrogant because he programs since he is 8 years old and in many languages and likes to humiliate persons. He said to me commands have to be inside the viewmodel.
I'm sorry this happened to you! This is an opinionated topic, so I suppose the team would have to agree on which approach to use. Commands in the view model are fine, but I still think there are situations where class commands thrive. It's a shame your boss will not get to experience class commands! 😄
Still way too complicated.
You want to create 100 classes of Commands if your ViewModel has 100 functions?
That sounds even more scary to maintain than just write the logic into the view model.
Hey Gnome, solid point. I still think relay/callback commands are appropriate in some cases, such as when the command is simple/only interacts with view model properties, or when reusability is not a concern. However, I'd be more concerned if I had a view model with 100 functions.