Confusion over IRepository

I'm a bit confused about when using the "IRepository pattern", when actually to load the data.

Currently I have something like this:

public class MainViewModel : ViewModelBase
{
    // EF4 generated ObjectContext 
    private ScorBotEntities context = new ScorBotEntities();         

    // Custom IUserRepository class
    private IUserRepository userRepository;

    public MainViewModel()
    {
        this.userRepository = new UserRepository(context.Users);
    }

    public ObservableCollection<User> Users
    {
        get
        {
            return new ObservableCollection<User>(userRepository.GetAll());
        }
    }
}

ScorBotEntities are autogenerated using EF4 (I had a look at POCOs, to much work for this sized project).

You can find the definition of the UserRepository here: http://code.google.com/p/i4prj4-g2/source/browse/ScorBotRobotics/ScorBotRobotics/Repositories/UserRepository.cs

But basically, what I'm wondering about is, why do it even make sense to use a repository here, instead of just writing it like this:

public开发者_如何学运维 class MainViewModel : ViewModelBase
{
    private ScorBotEntities context = new ScorBotEntities();         

    public MainViewModel()
    {
    }

    public ObservableCollection<User> Users
    {
        get
        {
            return new ObservableCollection<User>(context.Users);
        }
    }
}

It makes sense to abstract functionality away such as with the UsernameAndPassword method. But in that case, perhaps using some Query Objects would be more ideal?

I am a bit baffled that your context has made its way down to your ViewModel. I believe your GUI layer should never see the context. Context must be opened/kept/closed by the IRepository. Let the data layer (IRepository) return an array/list of Users.

There are a couple of different points here. First, your view models should have no knowledge of the repository - keep your view models as simple as possible.

Second, the IRepository is your public API - so you should have dependencies to this (depend on abstractions rather than concrete implementation between layers).

There are a couple of different (perfectly acceptable ways) to implement the IRepository. One is to have the repository encapsulate the context directly. Another is to use the "unit of work" pattern and have your unitOfWork encapsulate the context and pass the unitOfWork object to each repository. Either way, since you're using EF4, testability is much easier than it used to be. For example, EF4 introduced IObjectSet so that it is easy to provide test doubles and mocks to test your repository.

I highly recommend checking out this whitepaper on Testability and Entity Framework 4.

Separation of concerns

What if you want to change the storage of 'Users', from say SQL to a flat file?

Then context would not be needed, and you'd have to change every use of it, instead of just your IRepository implementation.

Also, ideally you would have your IRepository injected. So you're MainViewModel doesn't care how it gets it's Users.