What are the common relationships between Views, M

I'm working on a Windows Phone 7 app with a designer. I've done C# development with XNA so I know C# but was not familiar with the Model/View/ViewModel architecture.

Our first crack at it had multiple ViewModels active for any given view. Each ViewModel was an in-between layer for each object in our model.

For example: We had a "Friends" page that has a ListBox that displays the list of Friends. So we made a FriendsListViewModel that would handle getting an ObservableCollection<Friend> from the Model that the XAML would bind to. There were other functions available in the page (navigating to other pages, activating semi-related features, etc.) so that was contained in the FriendsPageViewModel.

This was starting to look crazy to me, so I made the relationship between View and ViewModel 1:1.

With all that described, I've got a question with two components: With MVVM, what is the common relationship between Views and ViewModels? (focusing on Windows Phone 7 development here in case it's any different from ASP.NET, WPF, or Silverlight)

And as a possible addon to that question: Say the 1:1 relationship is the generally correct or accepted one: If you're dealing with something like a Pivot control or Panorama control, would you typically give each PivotItem or PanoramaItem its own ViewModel?

In MVVM, you typically have one ViewModel for each View (exceptions exist). The View typically 'binds' to the ViewModel which is the glue between the view and the data model. Your view can contain multiple controls and each control will bind to a particular property (i.e. data source) on your ViewModel. The ViewModel will then notify the View once one of these properties is updated (via the INotifyPropertyChanged interface in C#).

When thinking about ViewModels, don't think of it as a single ViewModel per control. Think of the control binding to a single property of the shared ViewModel.

The ViewModel provides data from the model to the View. The View should only be used to display the data it gets from the ViewModel. Keep code in the View to a mimimum and only pertaining to rendering control elements. The ViewModel is responsible for querying data from whatever the data source may be and then providing public properties the View can hook into.

This MSDN link has a pretty detailed article on it, but you can get a good synopsis on wikipedia.