Factor ObservableObject into separate assembly
mwpowellhtx opened this issue · comments
Overview
I've got a case where I would like to base my models on the ObservableObject pattern, without necessarily having to roll my own. I've done so in a limited capacity with a ModelBase, for instance.
API breakdown
Toolkit is fantastic, but I am finding that I would not require the direct WPF support across the breadth of my solution adopting the observability. In addition to the ObservalbeObject, the messaging aspects might also be considered a strong factoring candidate, along similar lines, perhaps into the same, or similar such, assembly organization.
Usage example
For use supporting Windows Services automation, with a front end WPF XAML for configuration and such.
Breaking change?
I'm not sure
Alternatives
To roll my own, which I hate to "borrow" from the Toolkit, especially when it is available.
Additional context
In terms of breaking changes, not to the functionality of the packaged assets themselves. The only difference seen by subs would be the additional assemblie dependencies discovered during a NuGet package source shake down. Only separating out assemblies, for observability, messaging, etc. Apart from the more or less direct WPF usage, for instance.
I might be willing to help restructure a bit, but I'm not sure I know what the source gens are doing, landing in the buildable assembly, for starters.
Help us help you
Yes, but only if others can assist
What problem do you think doing this would solve?
As stated, I like having the observability, even the messaging, without needing the WPF aspects. Which obviously the WPF XAML aspects would not fit in terms of a Windows Service project. But the observability could.
What WPF aspects? The MVVM Toolkit doesn't reference WPF at all. But also, I asked you what problem would this solve. You replied saying "I like ...". That's not a problem being solved.
I may be confusing the CommunityToolkit.Mvvm.Input namespace, IRelayCommand pattern in particular. I suppose there's nothing about that which would be all that incongruent in another context, i.e. a Windows Service application. Closing for now, my apologies for the confusion.