Your question is really broad, but you might want to start out by deciding how your ViewModels are going to get their data and submit their updates through the EF classes.
While you can bind your EF types directly to your view I've found that a better approach is to keep your ViewModels separate from the ORM model types as much as possible. Model the needs of the View in terms of the behaviours (ICommands) and data (ViewModel props or child ViewModel props or ObservableObjects) apart from the EF types.
Then create a service type that can be injected or instantiated within the ViewModel that will interact with the data model directly and translate the ViewModels into Data Models and vice versa. You can either do that work manually, with LINQ/Lambdas, or using something like AutoMapper to define the relationship between your ViewModels and the data Models (EF Types). This maintains a clear line between the data schema and the ViewModels and I think you'll find changes in the data model having less of a ripple effect on your app this way.
That middle layer that I referred to as a 'service type' might just be some type that exposes a higher level interface than a repository focused more on business operations than on crud operations, but internally makes all the repository or EF calls on behalf of the viewmodels.
If you want to avoid using a framework that's fine, but you still should probably download the MVVM Light core libraries and have a look at what's included. Its pretty lean and will give you the basic nuts and bolts to support MVVM. You can choose to roll your own after that if you wish, but it might not be worth it.
EDIT: Since you said you're short on time...while I don't encourage it, a more expedient but less robust solution might be to just bind your views directly to your EF types as properties of your ViewModels.
// Using the ViewModelBase included in MVVM Light
// which gives you the special Set() method
public class EditCustomerViewModel: ViewModelBase{
public EditCustomerViewModel(){
_currentCustomerCommand = new RelayCommand(SaveCustomer);
}
private Customer _currentCustomer;
private void SaveCustomer(){
using(var ctx = new EfDataContext()){
// Save operation here
}
}
public Customer CurrentCustomer{
get { return _currentCustomer; }
set { Set(()=>CurrentCustomer, ref _currentCustomer, value); }
}
public ICommand SaveCustomerCommand{ get { return _saveCustomerCommand;}}
}
Then in your view you can bind your controls, whatever they may be to the CurrentCustomer properties. You can do your EF save via a command, displayed here as an implementation of the MVVM Light RelayCommand. So, quick and dirty approach could work, but if you can try to abstract the data models away from the ViewModels by presenting the data in types crafted explicitly to to serve the needs of the view.
