Why INavigationAware interfaces are in Prism.Wpf and not in Prism.Core?

[CorsairRO]

Hello Brian and Dan,

First of all i want to thank you for all of your nice stuff that you did with maintaining the PRISM Library alive.
Also, thank you Brian for the youtube free videos and paid pluralsight ones.

Now, i have some questions for you if you will have some time to look here.

I did develop an internal Application Framework for my company and we are using it in all of our Applications.
I am using some parts of PRISM like EventAggregator, DelegateCommand , Composite Command for my WPF App

When i looked at videos about how to use Navigation Aware and Regioning in my app i hit some walls there.

My App is structured in a totally different way then the apps that you and other people are showing in tutorials.
Meaning, i have a DataModels dll project, a Business dll that contains all my ViewModels and a UI Project that has all my Views.
The referencing is One Direction Only. So UI Knows about Business and Data. Business knows ONLY about Data, and NO UI.

The issue there is both DataModels and Business are NOT UI Aware, so they target net5.0 with no WPF dlls in there.
Therefore they are compatible with different UI Projects built on top of them, like a WPF, an Excel Plugin, a Blazor App, a Xamarin App and so on.

Also all my application logic is in a ViewModel found still in business. So i am using the ViewModel First Approach, and in UI i have DataTemplating to show corresponding Views.

I understood that the Regions are injecting views to them, but, what i strongly don't really like is that in addition to the RegionManager class that should know about UI Stuff, also the IRegionManager is included in Prism.WPF that has references to WPF specific stuff.
Same goes for NavigationAware Interfaces.

So why are the Interfaces in Prism.Wpf and not in Prism.Core that can be used in a business project that doesnt have anything with any UI Specific stuff.

How i am working with these services is that all my ViewModels works over an interface, that is resolved in the UI App to concrete implementations accordingly. So my ViewModels shows dialogs, toasts, accessing files and so on without knowing what they are doing until UI Project Unity Container resolves the Interfaces to specific classes.

So, in short, my question is:
Having the Interfaces in Prism.Wpf isnt it tight coupling all my projects to a specific platform?
In my opinion, the Interfaces should definitively go into Core, while the concrete classes should still be in Prism.Wpf
Also i would appreciate a lot if you show an example sometimes in youtube or pluralsight for the ViewModelFirst Approach

Sorry for being so long in the text,
Thank you in advance for your answers

[brianlagunas]

First off, VMs do not belong is in a Business DLL. If anything, they belong in their own DLL. You can still decouple your VMs by putting all your logic in a generic VM that sits in another assembly, while you have platform specific VMs (that derive from your generic VMs) in your app that handle the platform interfaces.

Secondly, Those interfaces cannot go into core because that would cause conflicts with other platforms. We already tried that, and it didn't work.

[CorsairRO]

hello Brian ,

OK, i got it with the interfaces that cannot go into core.

Thank you very much for your quick answer.
And keep up the nice work there.

Regarding the first assesment in your reply, i strongly disagree with it.
How i have built my framework is that VM are Business Logic in behind and have No reference where thy are going to be bound.

I am already using the same VM in WPF app, a Blazor App, an Excel tool and so on. My app is datacentric and it uses 500+tables and 200+ screens so i wouldnt say that it shouldnt work, as i made it to work like this, and it is very nice and totally decoupled from UI.

My Views have the DataContext set to my ViewModel and everything else is data binding / commanding / eventaggregator / services and stuff like this.

Maybe i am old school programmer, but i am very happy with my framework and how it works and how decoupled it is and so on.

Thank you again for your reply

[brianlagunas]

VMs are not business logic. VMs simply hold state for the view and respond to user interactions. Your business logic should be abstracted away from your VM via services.

Doesn't matter though, use what works for you. If it works, then great!

[CorsairRO]

I agree now on what you say. So i was just me not very clear in my post there.

VM's just holds state and interactions, and my real business logic is already abstracted away.

But why do i need to have 3 VM's that do exactly the same if i have 3 UI Projects there that uses the same functionality?
In my approach there 1 VM (Platform Agnostic) is just used in all of them. In Code Maintainability i think i get some advantages for that.

thank you again