2011-02-06 4 views
1

Je cherche des bonnes pratiques concernant la suppression de mon contexte de domaine RIA de mes modèles de vue pour les rendre indépendantes des sources de données. Il semble que la meilleure solution que je puisse trouver est le modèle d'agent de service tel que décrit here. Cependant, que se passe-t-il si j'ai une logique de requête relativement complexe à exécuter? Par exemple, actuellement, j'ai mes contextes de domaine dans mes modèles de vue. Disons que j'ai un ContactSearchViewModel, où il y a un peu de logique impliquée dans la construction de la requête de recherche:Modèle d'agent de service RIA WCF avec requêtes complexes

protected EntityQuery<Contact> CreateSearchQuery() 
    { 
     var query = Context.GetContactsQuery().Where(
         e => e.First_Name.ToLower().StartsWith(FirstNameSearch.ToLower()) && 
         e.Last_Name.ToLower().StartsWith(LastNameSearch.ToLower())); 
     if (!string.IsNullOrEmpty(Phone)) 
     { 
      query = query.Where(q => q.Phone == Phone || 
            q.Mobile == Phone || 
            q.Work == Phone); 
     } 
     if (SelectedContactType == "Prospect") 
     { 
      query = query.Where(q => q.Contact_Type_Id == 1); 
     } 
     else if (SelectedContactType == "Customer") 
     { 
      query = query.Where(q => q.Contact_Type_Id == 2); 
     } 
     return query; 
    } 

Maintenant, je pourrais bien sûr avoir une méthode d'agent de service avec une signature qui ressemble à quelque chose comme public EntityList<Contact> SearchContacts(string firstName, string lastName, string phone, ContactType contactType) mais imaginez si mon les requêtes de recherche étaient encore plus complexes - cette interface deviendrait lourde. Existe-t-il une meilleure alternative, d'une certaine manière je pourrais construire la requête dans la machine virtuelle comme je le fais avec le contexte de domaine? Ou devrais-je simplement l'aspirer et utiliser des objets de paramètres? Je préférerais de beaucoup pouvoir construire les requêtes sur la machine virtuelle, car j'ai actuellement une petite hiérarchie de machines virtuelles qui effectuent toutes différentes recherches en utilisant une classe de recherche de base et une méthode de modèle pour générer des requêtes, comme

enter image description here

Ne pas être en mesure de générer des requêtes du client causerait beaucoup de duplication de code que je fixe à l'aide de cette structure d'héritage.

+0

Je me souviens d'un moment où j'obtiendrais une tonne de réponses en quelques heures en posant une question comme celle-ci. Maintenant, les gens ne prennent que la peine de répondre à des questions simples. StackOverflow est vraiment descendu. –

+0

J'ai réfléchi à la même question récemment. Je ne suis pas vraiment intéressé à rendre agnostique la source de données VM (c'est vraiment beaucoup plus difficile qu'il n'y paraît), mais je voudrais certainement découpler les choses du DomainContext. Je pensais qu'une bonne approche pourrait être d'ajouter une méthode 'GetContactsQuery' à la couche de service qui a retourné un EntityQuery et ensuite ajouter une méthode 'LoadContacts' qui prend un EntityQuery. Une meilleure approche pourrait être de créer un type de requête pour «rejouer» la requête dans l'agent de service. Est-ce que l'une de ces approches semble raisonnable? –

Répondre

1

Je suggère de regarder dans le modèle de dépôt. Cela fait partie de DDD, mais a une application dans n'importe quelle architecture, IMO. Son but est de loger la logique de requête.

Il semble sale de donner à vos objets VM une logique de requête, à moins que ce soit single purpose.

+0

Ouais, merci. J'ai fini par utiliser un peu d'hybride entre le référentiel et l'agent de service. Pour les VMs, je parle de leur seul but est l'interrogation - ce sont des modèles de vue pour les vues de recherche. Tout ce qu'ils font est de collecter des termes de recherche (l'état d'affichage) et de les utiliser pour les requêtes (voir le comportement). –