Refactoring of ViewModels

Question

Background:
I am dealing with WPF solution that doesn't have good separation in accordance MVVM pattern. I need to improve architecture, readability, etc. My current issue is that I have MainVM with a huge amount of dependencies. MainVM corresponds to MainWindow view. MainVM is created on startup and holds as properties all other ViewModels of application. This MainVM is passed to all calls of Commands (ones who implement ICommand) and if some functionality needs its own ViewModel it references MainVM and reads a related property that holds needed ViewModel. Another issue is ViewModels are not separated from Models. My idea is to create a 'storage' for ViewModels (ideally Models but it is hard to achieve separation at this point) and access needed ViewModels from this storage and not from MainVM.
My application doesn't store anything, so the lifetime of this ViewModels storage will be the same as the lifetime of the application (static).

Now to my questions (rephrased):
1 - Is it common practice to access ViewModels from one 'main' ViewModel?
2 - What are possible drawbacks of using a separated storage for ViewModels and then Models in a WPF app?
3 - Should Commands (ones who implement ICommand) be dependent on ViewModels?

Rephrased question: 1 - Where to store ViewModels in WPF app?
2 - Is it possible to use Repository pattern to store Models in WPF?
3 - No modifications

Answer 1

1 - Is it common practice to access a ViewModel from one 'main' ViewModel?

Ans: No. This is a very bad design (if I call it a design). ViewModel should be designed in a way that it is agnostic of its parent and children, so that even if its hierarchy changes in future it would not effect any other module. It should only handle the properties, commands, events of the view it is backing. Any communication to children or parent viewmodels should happen via Events. It should definitly not refer the properties of parent or child VMs via direct reference. In this way you will have maintainable, testable app and wont run into the situation you are in right now.

2 - What are possible drawbacks of using a separated storage for ViewModels and then Models in a WPF app?

Ans: I assume by storage you mean the Model object that ViewModel will expose to View via its properties and commands. This Model should ideally be a business object of your application. Note that single ViewModel can have multiple models depending on the view design and features. But you should never ever access VM from the Model, which I think you are implying in your question. If you are not un-necessarily breaking your view into micro views to have like zillions viewmodels and models you should be fine.

3 - Should Commands (ones who implement ICommand) be dependent on ViewModels?

Ans: Commands also should be written in a manner that they can be re-used for similar type of operations across views.