You should definitely not make a huge "main view model" -- this is an anti-pattern not dissimilar to a god object.
The key idea here is that your viewmodels do not need to access several properties from other view models; rather, all of the viewmodels need to access specific pieces of information.
Right now you are most likely injecting this information into each viewmodel at the time of instantiation. Instead of doing this, provide each viewmodel with a reference to a service -- an application module that exposes this information through properties and/or methods. The information can be exposed in the form of scalar values if it's extremely simple in nature, or in the form of models if it's anything more complicated than that.
Schematically this would look like
/--------------
| ViewModelA |
| | <=======
| | |
--------------/ | <--- information is pulled /================
+=========[model]===[model]====== | Service |
/-------------- | ================/
| ViewModelB | |
| | <=======/
| |
--------------/
The service should be injected into the viewmodels upon construction (either manually or by the DI container if you are using one). Each viewmodel should only require a reference to the service and enough information to tell to the service which model it's interested in; it will then request that model from the service and populate its "interesting" properties based on that.
This way of doing things is more involved than simply constructing a viewmodel object and setting its properties externally, but it will allow your application to grow in complexity without becoming unmanageable.
For example, if there are lots of views that bind on different viewmodels and these viewmodels depend in complex ways on a number of models, a sane manner to work would be:
- A view/viewmodel pair is constructed
- The viewmodel requests any models it needs to know about from the service; it subscribes to an event that the service exposes to let subscribers know that a model has changed
- Changes are performed to the models through databound controls
- The view invokes a "save" command on the viewmodel
- In response to that, the viewmodel invokes a "save this model" method on the service
- The service persists the information and publishes a "model changed" event (see step 2)
- Other viewmodels interested in the same model know that the model has changed and can query the service for its new state
This is possible if everything is routed through the service. Imagine what it would take to keep everything synchronized otherwise -- the only way to cope would be to put all the information into a giant viewmodel and reference that from everything else. Ugly.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…