search

MarimerLLC / csla

A home for your business logic in any .NET application.
https://cslanet.com
MIT License
1.23k stars 394 forks source link

Consolidate UI neutral MVVM types into a Csla.Mvvm project #1766

Open rockfordlhotka opened 3 years ago

rockfordlhotka commented 3 years ago

As discussed here: https://github.com/MarimerLLC/csla/discussions/1765

There are a number of types (such as ViewModelBase) that are part of the Csla.Xaml and now Csla.Blazor packages/namespaces.

It would be cleaner and easier to work with if these types were in a Csla.Mvvm project, and those XAML/Blazor/etc. packages would only contain components specific to each UI framework.

rockfordlhotka commented 4 months ago

My view on viewmodels (see what I did there?) has evolved over the years, and so has the way .NET enables things like async operations.

The consistent part of the way CSLA supports a viewmodel is that there should be a Model property that directly exposes the object graph (or a single domain object) for binding in the UI. This is because a CSLA domain object fully supports data binding in ways that would be really hard to translate through a viewmodel (the viewmodel would have to do everything that's already done by BusinessBase and the other base classes).

All that said, the various ViewModel and ViewModelBase types in Csla.Xaml, Csla.Xamarin, Csla.Blazor and probably other namespaces are very disorganized and have lots of inconsistencies and also lots of duplicate code.

It would be very nice at this point, to create a Csla.Mvvm namespace in the main CSLA project that has a ViewModel<T> type that does all the common behaviors that should exist across all UI frameworks.

Certainly the XAML UI frameworks have a bunch of framework-specific stuff in them, like support for commands. Hopefully that code can be in a subclass of Csla.Mvvm.ViewModel that leverages the common code and adds XAML-specific support.

I suspect that Blazor won't need a specific subclass, but I might be wrong.

Given that you can (and I do) now use DI with Windows Forms, I suspect the MVVM design pattern might work really well in a truly modern (reimagined) WinForms app scenario - but to me this is optional, because I don't imagine too many people are starting new projects with Windows Forms.