I'm working on a project with MVVM. Some ViewModels have more than one repository.

  • Is ViewModels with more than one repository bad?
  • Please provide with why it's good/bad.

1 Answer 1



The purpose of the ViewModel is to abstract away where the data is stored, so that the View can display data in a way that makes sense for the user, but not necessarily data that matches the back-end. If you, for example have some data coming from a query in SQL, and some coming from a webservice to augment that data, then push that to the View using a single ViewModel, then I say you're doing exactly what it was designed for. You're abstracting away the complexity of the data being stored in multiple repositories for the view, so that whatever view you decide to use, you have an easy to use, concise ViewModel.


I have some data I need to gather and display:

  1. A contact table from the my database: UserID, FName, LName, Email
  2. Jobs that match me coming from the Indeed Job Search API
  3. My CV that comes from the StackApps API (I want to display background info on what was used to select the jobs via Indeed...like C# or Java jobs).

I roll all that up into a ViewModel:

  1. FirstName, LastName, an ArrayList of Jobs, and an ArrayList of relevant terms from my CV.

I want to display all that information on a single page, so the single ViewModel approach gives me a single object that I can display in my View. If I have multiple ViewModels for a single View, or try to do that aggregation and calculation in the View itself, then I undermine the benefits of the pattern, and I might as well go back to regular ASP.NET/Silverlight/whatever. If the Model changes, then I can change how those repositories get to the ViewModel, but the View doesn't care (nor should it), because it only cares about the ViewModel, not where the data is coming from.

  • Suppose the data source is one database. In this case shouldn't each ViewModel have only one repository? Commented Feb 23, 2011 at 15:37
  • @Amir: Yes, in that case it would, but that's still ok. Even it's in the same form as the database. It's really just an abstraction layer. Another scenario may be if you want to display a user's contact info, but don't want to display their street address they've entered to you. In that case the VM would be a subset of a single table in a single database. Even if it looks exactly like a table, the VM protects you from having to make front-end changes. You'd just have to change how the data on the back-end gets to the ViewModel and back.
    – Ryan Hayes
    Commented Feb 23, 2011 at 15:42
  • It's kind of strange than a ViewModel having different models. It lead to complex ViewModel since the ViewModel will handle GUI state of different models. IMO it's more natural to have one repository/ViewModel. Could you provide with a simple scenario that you proposal will be better? Commented Feb 23, 2011 at 15:43
  • @Amir: One repository/ViewModel is nice if you can do it, and it's fine if you have that. If you add a new repository or webservice or whatever on the back-end, then that's where you have multiple repositories mapped to a single ViewModel, and where you get to see the actual benefits.
    – Ryan Hayes
    Commented Feb 23, 2011 at 15:55
  • Thank you for you example! I'm thinking of when you have many repositories/ViewModel one should put each repository into a new ViewModel that is bond to a corresponding UserControls i.e. View. However when UserControl doesn’t work since the data is mixed together then it’s a must to have many repository/ViewModel. Is this you scenario you describing? Commented Feb 23, 2011 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.