I tell you what, I'm new to MVVM, and it seems like the amount of extra classes and code and workarounds needed to do things that should be simple, makes me question the value of using it.
I had been looking at lots of patterns and plenty of blogs and tutorials. This is the most robust pattern explained in the best way. I am very grateful for your output. Many thanks, Sean.
Youre good at this, but youre going too fast. Calm down, we arent all as smart as you! HAHAH, nice video, but try to be a little slower, explaning everything.
this is really really good. I cant bring myself to sit down and watch a 5 hr video on mvvm. This being split up into ~20min videos makes going through it that much more pleasant :).
Very nice tutorial! But I am concerned with this amount of overengineering in commands. Especially, OnViewModelPropertyChanged which is listener to another ViewModel's event. Is it a typical practice for MVVM? It just looks so weird. Couldn't we just create some validation event inside of Model to spectate if form data is valid to submit and change enabled state of our button? Next thing I am wonder about is that we duplicating fields of our Models inside ViewModels. Couldn't we use Model's fields for binding and watch changes in them somehow? For example, call the OnPropertyChange for entire Model and update all related xaml elements when some of Model's field changed? I came from frontend web-development and we use object observers to solve two-way data binding problem, so we can use entire models for binding fields to inputs. Is there a way to use same concepts in WPF, or it stands for MVVM exactly the way you've described in your guide videos? Thank you!
Is there a reason why you mix up business logic with model "code"? always thought that business logic should not reach the model section and instead the viewmodel section should be used.
I think he just did this because it's a small application, but it would be better i think to use a different project to put all your business logic in and use them in viewmodel
I've tried wpf in the past and spent considerable amount of time trying to nail these concepts down, failing miserably each time. but finally, finally I feel like I'm understanding things. Thank you so much.
I didn't get this at all... "You need this, then hop over here and do that, then add this, then do that.. now were done" is not a tutorial. Nor do I think "There is a better way to do it, but for now I'm gonna show you the crap way to do it for this purpose" is really a responsible decision. Do a search here for WPF Commands, and you will find very little help on the subject. What does is exist, is talking to you in such fractured, run together english you cannot understand it.. or it's the many "quick and crappy" ways you can implement it. Can someone please put out a video showing, from a program flow perspective, how a command is implemented.. as though your actually trying to TEACH someone?... because the "You peek over my shoulder while I slam this together in 2 minutes or less, while babbling" method doesn't work that well.
Hi Brian, I'm sorry this video didn't help you. I could certainly improve my teaching style, as not everyone learns by example. My video style is something I want to change up on this channel. Anyways, I don't know what other questions you have about WPF commands. At this point, it might be helpful to relieve your WPF command frustrations by hitting the IDE and implementing your learnings from this video. Trust me, you got this!
@@SingletonSean I really do appreciate most of your videos. They help a lot! I was probably a bit more brash on that comment than I would normally be, but I was so damn frustrated at that point (not being able to find any good, reliable videos on Commands) that you were the first one through the door after I loaded the shotgun (so to speak). I have your WPF MVVM course in my library, and I am going through it as I create this WPF MVVM app (gotta learn it)... because up until now, I did everything in Winforms. Mostly n-tier (where blurry lines between the tiers are expected). But MVVC is a totally different beast.. where you use commands instead of events to push functionality. And using call backs to the UI while pushing functionality to the ViewModels, using dependency injection to achieve optimum separation... I am finding it difficult to grasp some seemingly simple tasks (I say seemingly simple, because it would take me 2 minutes in WinForms to do it). It's almost as difficult as when I was learning Flex for Flash.. where everything was done on a single window, using states, transitions, and behaviors (lost a lot of hair over that). As far as learning, I prefer the RIGHT WAY first method.. then let the user figure out the shortcuts and "kludge" down the road. But you can't get that here.. most content is either someone cutting corners because it's "Only a tutorial" and it's good enough, or just flat out laziness on the authors side... so you end up with 10 different ways to do something (like commands) and never know if it's the RIGHT way (the MVVM way)... that is until you end up making a complete ass of yourself when another developer looks at your code while giving you "that look" like "why did you do it this way". Or you decide to open up your GIT, leaving more knowledgeable developers thinking "What a crap developer this guy is".. Sorta that same condescending, over superior attitude you get on Stack-Overflow when asking a question that wasn't put presented a specific acceptable way, lacked intellectual content, or (how dare you) asked a question that was far below an S.O. troll to even consider responding to.... Like "Q: Can I use a Winforms Timer in a DLL that has no UI?" to which the normal S.O. reply would be a very condescending "A: The OP hasn't given enough information to to accurately answer this question. Mod should close the post!". Seriously? I can tell exactly what the "OP" is asking, and so can all the minions.. but rather than help him out, they'd rather belittle him as though he's not worthy if a response... Now I mention this because a lot of other learning developers (the ones who have yet to reach GOD status like those on S.O.) get tired of that crap too, and go elsewhere for answers... "Hello RU-vid!". So this platform is important, especially for newbies. But your doing a good job.. just on some things, slow down a bit and show the BEST (RIGHT) way to do it. Thanks!
Should I dispose the command to unsubscribe the PropertyChanged? The ICommand does not implement IDisposable, so can I declare my command with command class name?
I working on desktop wpf app . Commands work only after intializing in the main viewmodel . Commands in the navigated viewmodels not working . The datacontext of the app linked with the main viewmodel. Can you help me ?
Hi Sean, nice tutorial! I'm just wondering if passing a ViewModel to a command is a best practice since you could reuse the command from many different views/viewModels. Even though you have an abstract ViewModelBase as a parameter, shouldn't it be a Model object instead? Thank you.
Hey David, great question! Reusing commands is one of the main reasons I'm a huge fan of class commands instead of delegate/callback commands. You're definitely on the right track by mentioning the abstract ViewModelBase. To support multiple view models in a command, I usually just define an interface that includes all the properties/methods that the command needs to use on the view model. Then, multiple view models can implement the interface and use the command. It also makes unit testing the command SUPER easy. I actually discuss this exact question in a part of another video! Here's a link to the timestamp: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-bYPU8X8f2xU.html
Hi @@SingletonSean You have a great answer how to use different view models in a command. I wonder from DI point of view how we should structure the code. The MakeReservationCommand needs MakeReservationViewModel in your code but generally you should inject the commands into view model, so we have cyclic dependency.
Hey Sean, fantastic tutorial so far, I learned so much from you after struggling for a while trying to learn about MVVM. I like the speed and editing of your videos, it really removes all the unneccesary parts, good job! I also like the fact that you did everything without a framework, and showed how it actually works just like that, its good to understand the basics. Keep it up, im excited to learn more from you! Joe
Hi Sean, awesome tutorial. You always seem able explain everything in a way that is both fun any easy to apply to ones own projects. Something that I've been trying to wrap my head around with commands is the best practice for the parameters. Most of the time I try to avoid using them all together by referencing the ViewModel/Store from the command class itself, but when I want to reuse the command multiple times I will bind the parameter to a property on the ViewModel. Currently my main issue is when you have a class command that has a task and that task can vary ever so slightly. Lets say for instance, you have an application that controls a light source with a command class called SetLightingProfile. In the view there are 4 buttons to set separate profiles. Easiest solution would be to pass a string with the profile name as a parameter and have a switch statement in the command. But this feels incredibly unstable and just ugly. So I was considering passing an enum that both the View and ViewModel know about. Am I overthinking this? Is it easier to just create 4 separate Command classes, even though they would be 95% identical?
Hey MsQlan, I think I understand your problem! I would prefer to have one command, so the key here is finding the right abstraction. As you suggested, a switch statement is unstable and somewhat difficult to maintain. Alternatively, you could abstract the "set lighting" behavior to an interface that your SetLightingProfileCommand uses, and use polymorphism to implement the various set lighting behaviors. On the other hand, I could be overthinking this hahah. Perhaps an abstraction would be overkill. Nonetheless, I hope this inspires some other ideas. Please let me know if you have any other questions, your comments on this channel have definitely been enjoyable to think about!!
Hey sean, Thank you for uploading such complex topics in such detail, really love your work I was wondering at 8:54, is it better or worse to use XAML to accomplish the same thing, BInding the enabled property of the button to a converter that returns true or false for the textbox value changed property Thank You again, Learn from you every day
Great video series, thank you. Now just asking, instead of manually creating the logic for INotifyPropertyChanged and ICommand, why not simply using "CommunityToolkit.Mvvm" package?
Hi Franck! This is a good suggestion. I haven't gotten around to experimenting with that package yet, but I'll have to give it a shot. Perhaps I'll do a short walkthrough of the package too!
I think that by doing things manually, a new person such as myself learn how the system works. I have tried other tutorials which used packages and the packages obfuscate the basics.
When implementing this CommandBase, what to do if the button is inside a RadioButton and CanExecute is false to not focus RadioButton? Because when I click on the button, the RadioButton IsChecked property becomes true. How do I stop changing parent focus or whatever event fire?
Hey awesome tutorials I'm sure more people will find them over the years. I am wondering tho, whenever you say let's implement that what key combination are you clicking? I'd love to know the magic of code appearing.
Hey Human Rayla, I usually do all the magic through CTRL + . (period). That brings up the little context menu with all the useful code generation and quick actions.
Hi there, very nice series , congratulation. I have a question: when you implementing BaseCommand deriving from ICommand you include System.Windows.Input. I guess this is needed for the binding to work with the canExecute, ecc and update automatically the UI. As BaseCommand , if I got it right, should be part of the VieModel layer, isn't this implementation binding the logic to the View ?
Great tutorial, Sean. 10:05 I'm a little concerned with the implicit subscriber to CanExecuteChanged event here because we actually didn't subscribe a method to the event that refreshes the UI and checks the value of CanExecute method to make the button enabled again if it returns true. So I assume the subscriber is implicitly implemented here? Is it coming from the Button control or somewhere else?
I have another question in regards to the design. It seems we are passing our hotel and other models way down the view hierarchy, to the point where a command needs to know about a model. This makes our view and viewmodel tightly coupled with the model itself. Isn't this somethign we are trying to avoid?
I think it makes sense for the view model and commands (I'd consider commands to be a part of the view model layer in MVVM) to know about the model. Data needs to get propagated between the view model and the model somehow, so I think the view model layer should be responsible for this. Of course, we could create abstractions to loosen these dependencies if necessary.
@@SingletonSean Thank you for the reply! I wanted to ask something else, do you have a tutorial about updating the ui from a different thread? For example if i have a command that runs a long task in Task.run, if I'm trying to receive events from that task to update the UI in getting an exception. For example if the task calculates the Fibonacci sequence an every number it finds it invokes an event with a string argument saying "next number is X". And my model view is subscribed to this event. And updates the ui bindings. Is there a correct way to do such updates?
hey isn't this bad practice, view model has Icommand property and Command has view model instance? it is like weird cyclic reference... how can this be avoided?
Good question Gagandeep! We can remove the cyclic reference via a factory, as demonstrated in this video: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-t2Gs-dYz-7k.html This also removes the hard dependency that the view model has on the command.
Good question David! I have the perfect video for you: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-bYPU8X8f2xU.html Let me know if you have any questions or counter arguments! I will say that in many situations, RelayCommand is perfectly fine.
Hi Sean, Wouldn't it be easier, at least in this application's case, to implement INotifyPropertyChanged in the Model rather than the ViewModel? My reasoning is that it'll primarily save you from having to raise it in the ViewModel and again for some of the same variables in the Command Class. Since it's not UI specific, it can go in either ViewModel and Model according to official Microsoft documentation. Thanks in advance for your time and thoughts!
He's building this application as a demo for more complex applications. But in general, you'll want to separate them, even if the ViewModel does nothing except access the Model and raise OnPropertyChanged. I've implemented INotifyPropertyChanged on simple models but in almost every case I had to go back and separate them later as my application evolved. And at that point I'm spending more time that it would've taken to separate them at the beginning.
after each video lesson I watch, I try to comment on the classes and methods that I have written, and I am grateful to you that you explain and tell me so clearly and easily that I do not have any questions about what and why. Thanks!
