Sean, thank you for demonstrating how to plug in the CommunityToolkit.Mvvm into a XAML-based project. I am getting myself familiar with WinUI 3 where such a practical show-round is very appreciated. I have used the Prism Library in previous WPF projects but it is not under active development much and the community toolkit seems a bit more actively updated and flexible.
Thank you! Very helpful. I have the same problem with the validation targeting way too much with red. The default really should be just the object bound to the property that is reporting the validation error.
Love this video! Could you please add this video to your another playlist "WPF MVVM TUTORIAL" as well, it will definitely help people to utilize that library and boost their learning.
On the viewmodel where you use messenger and error stuff, you should be able to do the inhertiance exactly the other way around and use the Observable Validator as Attribute instead ?! That would save you the additional interface for Navigation (btw. you can use all those base classes as attribute... and inherit from something else. It´s going to generate the base class code in the partial then) The Recipient does have the Messenger as Parameter to the ObservableReciepient base constructor (uses weak one if you don´t pass any). Reason beeing that the Base class can´t know which Messenger you wanna use (weak vs. strong). --> That would probably explain why you had troubles with register and unregister ?!
Thanks for your videos! I have a non-parameterless constructor in my viewmodel. Then I set the DataContext to the viewmodel in the view’s constructor. I get an instance of the viewmodel from DI either by putting the viewmodel in the view’s constructor, or ‘App.Current.Host.Services.GetService()’ . Is this OK? How would you set the DataContext to a viewmodel that has a non-parameterless constructor?
While this is nice and the code looks nicer, it is another dependency that we do not really need. I think with modern IDE and tooling, boilerplate is nowhere near the hassle that it once used to be. Overriding parts of a setter obscures what is really going on. When you got to the validation part, I think that code quickly becomes unreadable if you have complex interactions.
Since 2021, I do web dev (mostly frontend w/ React) in my day-to-day work. I've always loved the web so it was only a matter of time. I still follow desktop dev since I spent so much time on it in the past. Plus, most of the frontend web concepts apply to desktop dev anyways!
(Re-posting, as my comment vanished for some reason) Considering an alternative to Caliburn for my WPF app, and taking a deeper look into this toolkit. What you've shown here so far looks great, especially the excess boilerplate auto-generation ! I'd like to know though, how did you get x:Bind to work ? My VisualStudio is throwing an error that x:Bind is not supported in WPF, and simply wouldn't recognize it. I've also set the data context in code-behind, following the official Microsoft guide for MVVM Toolkit - but it didn't really help.
Wouldn't MVVM tool kit cause unnecessary overhead due to the use of the source generator and attributes. If so, how much of a performance hit would this library be on an application
Source code generation should only run on code changes in the relevant files, so it should not even affect the build to much. But as said in another comment, on bigger projects VS may be bugging out a bit... expeerianced that quite some times myself. ---> On Runtime it should mostly even should be a performance+ in a lot of cases, since all the notifications and such stuff only happens when needed (no use of any Requery Suggested anymore).
Not sure any MSFT employee is watching this video, the VS IDE does have a problem with the Source Generator in my experience. Sometimes restarting VS may resolve the problem, but sometimes it drives me crazy. SG may be a good idea, but VS team doesn't take it seriously enough. I feel much less problematic with Rider.
Good question! A page view model is essentially the root view model of a specific page. As opposed to a component view model, which would be the view model for a component / part of the page. A page view model could be made up of many component view models.
Good question! Stores contain, manage, and centralize application state, and allow communication between components of your application (ex: view model communication). So for example, one view model in a todo list application might load all the todo items into a TodoStore. Then, another view model might add a todo item to the TodoStore. Since everything flows through the TodoStore, all the view models in the application can instantly update with the loaded and added todo items. On the other hand, services are stateless. They perform some sort of business logic, fetch data from a data store, etc. So in the todo list example, the TodoStore might use a TodoService to fetch the todo list items from the database. I was asked a similar question on the Discord channel a few weeks ago, so I am planning to create a whole video on this topic!
Says C# is a good language for not having multiple inheritance, then proceeds to use quirky workarounds to lack of this feature, saying: "it's okay it sometimes has to be like that". But seriously, to be honest I don't see that much trouble in including multi-inheritance in your language. C++'s resolution of the diamond problem always seemed simple and straightforward to me, so I'm not sure, why people still say it's bad.
I never have done MVVM from scratch anyway, it's called a Class Library for a reason. You should never be doing MVVM completely form scratch all the time. You put the basics in a class library and then you add on to that.
As someone who has been developing a desktop WPF app manually creating all the code, this is exactly what I needed and wanted to do for a while now
Yep, I used to do it all manually too! Such a time saver.
Why would you add complexity for no real gain?
Sean, thank you for demonstrating how to plug in the CommunityToolkit.Mvvm into a XAML-based project. I am getting myself familiar with WinUI 3 where such a practical show-round is very appreciated. I have used the Prism Library in previous WPF projects but it is not under active development much and the community toolkit seems a bit more actively updated and flexible.
Hell yeah, finally an episode on this one
The video and the source code are excellent. Best way to learn mvvm toolkit.
Thank you! Very helpful. I have the same problem with the validation targeting way too much with red. The default really should be just the object bound to the property that is reporting the validation error.
Love this video! Could you please add this video to your another playlist "WPF MVVM TUTORIAL" as well, it will definitely help people to utilize that library and boost their learning.
On the viewmodel where you use messenger and error stuff, you should be able to do the inhertiance exactly the other way around and use the Observable Validator as Attribute instead ?! That would save you the additional interface for Navigation (btw. you can use all those base classes as attribute... and inherit from something else. It´s going to generate the base class code in the partial then)
The Recipient does have the Messenger as Parameter to the ObservableReciepient base constructor (uses weak one if you don´t pass any). Reason beeing that the Base class can´t know which Messenger you wanna use (weak vs. strong). --> That would probably explain why you had troubles with register and unregister ?!
Thanks for the video. Appreciated 🙏
Thanks for your videos! I have a non-parameterless constructor in my viewmodel. Then I set the DataContext to the viewmodel in the view’s constructor. I get an instance of the viewmodel from DI either by putting the viewmodel in the view’s constructor, or ‘App.Current.Host.Services.GetService()’ . Is this OK? How would you set the DataContext to a viewmodel that has a non-parameterless constructor?
While this is nice and the code looks nicer, it is another dependency that we do not really need. I think with modern IDE and tooling, boilerplate is nowhere near the hassle that it once used to be. Overriding parts of a setter obscures what is really going on. When you got to the validation part, I think that code quickly becomes unreadable if you have complex interactions.
Hey Sean - I watch your channel regularly. Do you work with desktop day-to-day? Do you feel like switching to web dev? :P
Cheers.
Since 2021, I do web dev (mostly frontend w/ React) in my day-to-day work. I've always loved the web so it was only a matter of time.
I still follow desktop dev since I spent so much time on it in the past. Plus, most of the frontend web concepts apply to desktop dev anyways!
(Re-posting, as my comment vanished for some reason)
Considering an alternative to Caliburn for my WPF app, and taking a deeper look into this toolkit. What you've shown here so far looks great, especially the excess boilerplate auto-generation !
I'd like to know though, how did you get x:Bind to work ? My VisualStudio is throwing an error that x:Bind is not supported in WPF, and simply wouldn't recognize it.
I've also set the data context in code-behind, following the official Microsoft guide for MVVM Toolkit - but it didn't really help.
Great video tutorial. Thank You.
Wouldn't MVVM tool kit cause unnecessary overhead due to the use of the source generator and attributes. If so, how much of a performance hit would this library be on an application
It could slow down builds, but from my understanding I don't think source generators have any serious performance implications at runtime.
Source code generation should only run on code changes in the relevant files, so it should not even affect the build to much.
But as said in another comment, on bigger projects VS may be bugging out a bit... expeerianced that quite some times myself.
---> On Runtime it should mostly even should be a performance+ in a lot of cases, since all the notifications and such stuff only happens when needed (no use of any Requery Suggested anymore).
Not sure any MSFT employee is watching this video, the VS IDE does have a problem with the Source Generator in my experience. Sometimes restarting VS may resolve the problem, but sometimes it drives me crazy. SG may be a good idea, but VS team doesn't take it seriously enough. I feel much less problematic with Rider.
DependencyPropertyGenerator - Another thing to remove boilerplate if you create custom controls
Will there be any tut about building a WPF app with MVVM Toolkit from scratch?
What do you mean by "page level view model"?
Good question! A page view model is essentially the root view model of a specific page. As opposed to a component view model, which would be the view model for a component / part of the page. A page view model could be made up of many component view models.
Thanks a lot 👍
what's the purpose of services and stores folders
Good question! Stores contain, manage, and centralize application state, and allow communication between components of your application (ex: view model communication). So for example, one view model in a todo list application might load all the todo items into a TodoStore. Then, another view model might add a todo item to the TodoStore. Since everything flows through the TodoStore, all the view models in the application can instantly update with the loaded and added todo items.
On the other hand, services are stateless. They perform some sort of business logic, fetch data from a data store, etc. So in the todo list example, the TodoStore might use a TodoService to fetch the todo list items from the database.
I was asked a similar question on the Discord channel a few weeks ago, so I am planning to create a whole video on this topic!
ReactiveUI is my choice for MVVM with MAUI, WPF, etc.
Always wanted to try ReactiveUI, but never got around to it!
Says C# is a good language for not having multiple inheritance, then proceeds to use quirky workarounds to lack of this feature, saying: "it's okay it sometimes has to be like that".
But seriously, to be honest I don't see that much trouble in including multi-inheritance in your language. C++'s resolution of the diamond problem always seemed simple and straightforward to me, so I'm not sure, why people still say it's bad.
I never have done MVVM from scratch anyway, it's called a Class Library for a reason. You should never be doing MVVM completely form scratch all the time. You put the basics in a class library and then you add on to that.