mvvm référentiel de filtrage

Question

J'ai un maître-détail des classes basées en grande partie sur Josh Smith article msdn.Son grand code, surtout pour un exemple, mais me laisse vous vous demandez comment gérer au mieux les situations où vous voulez quelques sous-ensemble d'un référentiel.

Donc, Josh a une classe appelée AllCustomersViewModel, et le code quelque chose comme:

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

Comment résoudre une situation où vous voulez PreferredCustomers, ExCustomers, LocalCustomers, etc, etc??

Son code me suggère un ViewModel de la classe pour chaque, avec le filtrage du référentiel codé en dur dans la classe.

Ou bien un moyen de passer un filtre optionnel dans le ViewModel avec le référentiel?

Comment est-ce que votre code de résoudre ce problème particulier?

En passant, quelqu'un aurait-il des liens ou des bons exemples montrant comment utiliser SpeciaficationPattern IQueryable pour résoudre les questions de ce genre?

Cheers,
Berryl

Answer 1

Une option (et probablement le plus propre) est tout simplement ajouter ces méthodes à l' CustomerRepository - par exemple, GetPreferredCustomers(), GetLocalCustomers() etc.

Aussi, vous devriez vraiment travailler contre les abstractions, devrait donc passer un ICustomerRepository pour votre modèle de vue du constructeur.Cette dissocie le modèle de vue que le code de votre béton client référentiel (dans ce cas celui qui lit à partir d'un fichier XML), et il est facile d'échanger les implémentations, par ex.pour les tests unitaires.

L'autre option, comme vous le mentionnez, est pour votre référentiel d'exposer IQueryable<T>.Si vous êtes heureux d'être lié dans IQueryable, et nous sommes confiants que tout accès aux données de la mise en œuvre va à l'appui d'une LINQ fournisseur, qui offre une bonne flexibilité.Voir ici pour plus d'info.

Personnellement, je préfère la première option, en particulier pour les grandes applications à grande échelle.