In an overly simplified answer, your ViewModel should contain the LOGIC for controlling what your View displays, and also how it is aloud to interact with the Model or Data.
Events like Getting data, Saving and Deleting are intercepted through a Command mechanism and pushed into the ViewModel, where they can be tested. Handling 'Dirty' events are also the duty of the ViewModel. As for who Calls the ViewModel, you are entrusting the Calling to the Binding mechanisms available within WPF and Silverlight.
Within the ViewModel it is still about staying with best practices and ensuring that you have a DataAccess layer abstracting your Data Source and possibly using the Repository pattern to abstract that.
The life cycle of a ViewModel could be as simple as the following...
- Constructor called by View
- GetData method called by ViewModel Ctor
- Data received and pushed into existing View databound ObservableCollection property
However since you will probably have a lot of moving parts within the Ctor of the VM, including the Data Repositories Interface you will probably want to work with an IoC. This will make the life cycle of the ViewModel closer to...
- View/ViewModel (Depends if you are View or ViewModel first) is pulled out of the IoC
- IoC Handles the pairing of the View-ViewModel (Convention based)
- Data Repository is Injected into the ViewModel
- GetData method called by ViewModel Ctor
- Data received and pushed into existing View databound ObservableCollection property
This may seem like more steps, however with an IoC container you are really just calling a single method like IoC.Get(), and the rest of the steps are wired up automatically based on the conventions applied.