mvvm repository filtering

Question

I have some master-detail classes based in large part on Josh Smith's msdn article. Its great code, especially for an example, but leaves me wondering how best to handle situations where you want some subset of a repository.

So Josh has a class called AllCustomersViewModel, and code something like:

    public AllCustomersViewModel(CustomerRepository customerRepository)
    {
        if (customerRepository == null) throw new ArgumentNullException("customerRepository");

        // Populate the AllCustomers collection with CustomerViewModels.
         _allCustomers = _customerRepository
            .GetCustomers()
            .Select(cust => new CustomerViewModel(cust, _customerRepository))
            .ToList();
   }

How do you solve a situation where you want PreferredCustomers, ExCustomers, LocalCustomers, etc, etc??

His code suggests to me a ViewModel class for each, with the filtering of the repository hard-coded in that class.

Or else a way to pass an optional filter into the ViewModel along with the repository?

How does your code solve this particular problem?

As an aside, does anyone have links or good examples showing how to use SpeciaficationPattern or IQueryable to solve issues like this?

Cheers,
Berryl

Josh spends a little time here now. You might get lucky. – Rick Sladkey May 23 '11 at 00:52 — Rick Sladkey, May 23 '11 at 00:52

devdigital · Accepted Answer · 2011-05-23T09:09:21.997

1

One option (and probably the cleanest) is to simply add those methods to the CustomerRepository - e.g. GetPreferredCustomers(), GetLocalCustomers() etc.

Also, you should really be working against abstractions, so should pass an ICustomerRepository to your view model constructor. This decouples your view model code from your concrete customer repository (in this case one that reads from an XML file), and makes it easy to swap out implementations, e.g. for unit testing.

The other option, as you mention, is for your repository to expose IQueryable<T>. If you are happy to be tied into IQueryable, and are confident that any data access implementation is going to support a LINQ provider, then that provides good flexibility. See here for more info.

Personally, I prefer the first option, particularly for larger scale applications.

edited May 23 '11 at 09:09

answered May 23 '11 at 09:01

devdigital

34,151
9
98
120

Agreed on the use of an interface for the repository, and I do use one. But it isn't really enough; for instance, what if GetLocalCustomers() require's a parameter, perhaps a zip code to define what's local - where does *that* go? Will look at your link, and am also looking at [this one](http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/) by Udi Dahn. Cheers – Berryl May 23 '11 at 13:01
That would go on your ICustomerRepository interface and concrete implementation – devdigital May 23 '11 at 13:10

mvvm repository filtering

1 Answers1