Filtro del repository MVVM.

Question

Ho alcune classi matrimoniali con sede in gran parte su Josh Smith's Articolo MSDN.Il suo grande codice, specialmente per un esempio, ma mi lascia chiedersi come meglio gestire le situazioni in cui desideri del sottoinsieme di un repository.

Quindi Josh ha una classe chiamata AllCustomersviewModel e codice simile a qualcosa come:

    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();
   }

.

Come risolvi una situazione in cui si desidera che vuoi clienti preferiti, clienti clienti, locali clienti, ecc., ecc.

Il suo codice mi suggerisce una classe ViewModel per ciascuna, con il filtraggio del repository codificato rigido in quella classe.

Oppure un modo per passare un filtro opzionale nel ViewModel insieme al repository?

In che modo il tuo codice risolve questo particolare problema?

In qualità di a parte, qualcuno ha collegamenti o buoni esempi che mostrano come utilizzare SpeciaFicationPattern o IQureyable per risolvere problemi come questo?

Cheers,
Berryl

Answer 1

un'opzione (e probabilmente il più pulito) è semplicemente aggiungere tali metodi al CustomerRepository - E.G.GetPreferredCustomers(), GetLocalCustomers() ecc.

Inoltre, dovresti davvero lavorare contro le astrazioni, quindi dovrebbe passare un ICustomerRepository al tuo construttore del modello di visualizzazione.Questo disaccoppia il tuo codice modello di visualizzazione dal tuo repository del cliente concreto (in questo caso uno che legge da un file XML) e semplifica la scambiature implementazioni, ad es.Per il test dell'unità.

L'altra opzione, come si menziona, è che il tuo repository esporre IQueryable<T>.Se sei felice di essere legato in iqueryable e sono fiducioso che qualsiasi implementazione di accesso ai dati supporterà un provider LINQ, quindi fornisce una buona flessibilità.Vedi qui per maggiori informazioni. Personalmente, preferisco la prima opzione, in particolare per applicazioni su larga scala.