Application architecture in scope of configuration, viewsets and dockable windows

Description

I have an C#/WPF application that uses MVVM pattern and PRISM. My app has viewsets, dockable single- and multi-instance windows. There are user settings (window size, position), workspace settings (viewsets, docking layout, column sizes, python scripts, list of entries in watch windows, logging intervals per entry, etc.) and project settings (a hierarchical list of entries with additional properties) all stored as XML files using custom serializers. App is made in a very generic manner, modules 'doesn't know' about each other, partially PRISM service locator is used and partially DI, PRISM events are tuned down to absolute minimum.

Issue

I will now consider only workspace settings - they are managed by ConfigurationManager. ViewSetManager is responsible for managing viewsets and DockingManager is responsible for serializing/deserializing window layout for selected viewset. There is additional NavigationManager that provides a wrapper for PRISM regarding getting a list of views/viewmodels and navigating considering the fact that there are multiple viewsets.

Currently ConfigurationManager exposes Loading, Loaded, Saving, Saved events. To these events is subscribed ViesetManager (in order to recreate viewsets, when new configuration is loaded) and DockingManager (to perform required serializations).

ViewSetManager has ViewSetChanged event. To that event is subscribed ConfigurationManager (to know when viewset has been added/removed/changed by user) and DockingManager (to perform required serializations). It's worth noting that ViewSetManager is an entity instantiated inside ConfigurationManager.

As you can see, this approach is quite complicated and error prone.

Question

1. Who's responsibility is to manage all the connection between ConfigurationManager, ViewSetManager, DockingManager?
   • Should it be done with events or maybe by additional mediator or perhaps ShellViewModel?
   • How it should be ideally done?
2. Should ConfigurationManager instantiate any complex objects that manage application or should simply provide basic properties to be used by other parts of the app?

Bonus Question

3. Should ConfigurationManager be a single entity responsible for serialization/deserialization, watching file and providing settings or it should be divided into two separate entities - one responsible for file operations and one for settings provisioning?

Possible solutions

I am redesigning mentioned architecture. In a new approach an area that will display all the views is called ViewSetRegion - it manages viewsets and when new DockingControl is added (perhaps by ViewSetManager) it creates new dynamic DockingRegions, which can be populated with views from different part of the app. I believe this is quite clean design, however I am unsure how to connect this part of the application with ConfigurationManager.

Final note

If you could provide me at least answers to those questions or any meaningful articles on this topic or an actual application design I would be grateful :)