Csla.Xaml ViewModel type feels old

[rockfordlhotka]

Maybe it is just because I haven't done a lot of Xaml for a long time, but I'm testing CSLA 6 by creating a new WpfExample app, and I must say that the Csla.Xaml.ViewModel<T> type feels very old and outdated compared to the comparable type we have for Blazor.

I'm seriously thinking about reworking the type to be more modern, though that'd completely break users of the existing type.

Do you use WPF? Do you like the existing type? Or do you wish it was easier to work with?

Again, it could be just that I'm not in the "Xaml mindset" anymore, and the current type is good, and it is just me 😄

[rockfordlhotka]

Here's the current WpfExample code for review

https://github.com/MarimerLLC/csla/tree/main/Samples/WpfExample

I think maybe my problem is that I used to focus on having absolutely zero code-behind a WPF page. With Blazor I've become accustomed to having some bits of code-behind.

The existing Xaml ViewModel type is designed around commanding and directly handling UI events, while the Blazor ViewModel type is optimized to simplify those little bits of code-behind.

[kcabral817]

I have an entire enterprise application (115 screens) built on WPF and use the ViewModel. There's so many breaking changes with WCF and others that I'd like not to do this one. It's easy to understand, view and there's no code-behind. Can we please let this one stay?

[rockfordlhotka]

Thank you @kcabral817 - this is exactly why I brought this up for discussion. This isn't the sort of thing I should decide unilaterally.

[rockfordlhotka]

Actually, I think I found a compromise.

I changed ViewModel so it isn't abstract, and made the RefreshAsync and SaveAsync methods public. That allows a code-behind approach to using the type, and allows the type to be accessed via dependency injection.

63895f8#diff-d4e2c500f7a3998c87a27b6e8d8a308b7d8d518bd31b3f145631d62a655a86ed

This shouldn't change any existing behaviors on the type or subclasses of the type, and so shouldn't affect existing code.

[danielmartind]

I think I prefer the existing way of keeping code out of code behind although might give it a go and see how I get on with how you are suggesting. Not sure how testable code behind in WPF is?

[rockfordlhotka]

There's no doubt that code-behind in WPF is hard/impossible to test. I've just gotten into some "bad" habits with all the Blazor I've been doing 😀