Silverlight MVVM – Creating Controls Dynamically in Code-Behind or ViewModel

Navigation should always be handled in the ViewModel.

You're on the right track with thinking that the perfect implementation of the MVVM design pattern would mean you could run your application entirely without Views, and you can't do that if your Views control your Navigation.

I usually have an ApplicationViewModel, or ShellViewModel, which handles the overall state of my application. This includes the CurrentPage (which is a ViewModel) and the code for handling ChangePageEvents. (It's often also used for other application-wide objects such as the CurrentUser, or ErrorMessages too)

So if any ViewModel, anywhere, broadcasts a ChangePageEvent(new SomePageViewModel), the ShellViewModel will pickup that message and switch the CurrentPage to whatever page was specified in the message.

I actually wrote a blog post about Navigation with MVVM if you're interested

As a general rule, it is not a good idea to expose a Model object in a ViewModel object. The form of the ViewModel class should be determined by the needs of the View that will use it. The form of the Model class should be determined by the concerns of your data model.

In my experience with Entity Framework and the MVVM pattern, I have found it best to transform the EF data as I populate my ViewModel object. The ViewModel object will then contain the data from the data model but in a different form. If you need to allow the user to change data, then you often want to have methods that transform the modified ViewModel data back into Model data so that you can persist it to your data store.