View Model Communication/Messaging - EASY WPF (.NET 5) 

Thanks Marc, glad the tutorials are helpful!

Indeed! If I had your tutorials 10 years ago when I tried WPF the first time, I would've been soooo much more productive and happy! I just donated to you. You should start a patreon or github sponsorship :)

I just saw we can join your channel

That's great to hear geocine! I'm actually a React developer, so a lot of the WPF decisions I make are inspired by experiences with front-end JS frameworks! I'll definitely be covering those topics as I move more into covering the essentials of building WPF apps.

Thanks Ivandro :)

Thanks Adrian! You won't be waiting much longer, stay tuned this week. I'm finishing up editing one navigation video, but I expect this to be a series. It will be fun.

@@SingletonSean Could you show in the video how to add a popup as well? Thank you.

Good question Purswani! It would definitely be a similar approach. In this demo, the CreateProduct and ProductListing view models were completely separate from each other, so moving each of those to separate views would result in the same functionality. Regardless, I plan to expand on this concept because it's crucial for WPF/front-end applications. I'll definitely get into edit/delete updates when I do my video on managing application state, because I think it's more related to that concept. Unfortunately, that was all a little bit outside the scope of this tutorial since I just wanted to focus on the communication aspect. But stay tuned!

Hey triplehoon, that's a good question. In most cases, it's probably fine to make it static, but I think there are some drawbacks. For example, what if you really wanted multiple instances of a store? This is unlikely in most cases, but I could image how it could happen in larger apps. The other issue with static classes is that they cannot implement interfaces. This causes tight coupling with consumers, and makes testing and mocking difficult. Singletons can implement interfaces, but tight coupling is still an issue if consumer aren't depending on an interface and using constructor injection. Overall, I just prefer to stay away from static classes and singletons. With .NET's dependency injection capabilities, I find it much easier to just inject dependencies through the constructor. It's also nice being able to see what a class depends on just from looking at a constructor, rather than sifting through every method looking for static/singleton class references.

@@SingletonSean Wow. Thank you for a detailed answer. It really helps me to understand your concept of communicating between view models.

Good idea Miguel, I will consider expanding on this. In the mean time, here's a good article that summarizes the issue: michaelscodingspot.com/ways-to-cause-memory-leaks-in-dotnet/#:~:text=WPF%20Bindings%20can%20actually%20cause,a%20memory%20leak%20(explanation).

@@SingletonSean awesome. Thanks for the link. It is extremely helpful

Good question Zeroes and Ones. That is known as a get accessor property: docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/using-properties#the-get-accessor

@@SingletonSean so, is this basically a readonly property? I have been using e.g. public string Name { get; }

Good point Dragos, as someone who builds web apps (usually Vue as well, go Vue!), I feel the same way sometimes. I don't necessarily think Microsoft made it difficult on purpose. Keep in mind WPF was born over a decade ago and quite a while before the birth of reactive JS frameworks. That said, it's kind of surprising how powerful WPF is in terms of reactivity and MVVM. Electron is great. I've used it a few times and it gets the job done. A bit buggy, a tad slower, takes up more space, but great tool. Feels great using JS, and also destroys WPF in terms of building responsive apps. Cross-platform is useful too. So why use WPF? The strongly typed C# is nice, but also contributes to the reason that it feels difficult. It's also a native Windows app, so it's more performant than Electron and allows us to interact with Windows specific APIs easier (registries, file systems, etc.). It's quirky, but I can't see electron ever replacing WPF entirely.

Hey mike, I am not using Prism. I feel comfortable with the raw power of WPF, and do not feel a framework is necessary. Perhaps I'll try one when I feel I need it though!

@@SingletonSean many thanks for your response , you're doing a great tutorials, is there a dedicated video to MVVM, I'm sure you have a lot to say.

Hey Mak, I agree! That is why we setup the mediator in this video. I'm assuming this comment is just a summary of the video.

Always good information, but I did like it better when you did things a little slower. A little hard to follow (at least for me)