2010-12-15 79 views
0

J'ai un scénario dans lequel j'aimerais filtrer certains ensembles d'entités au niveau du modèle, pas au niveau de la requête, c'est-à-dire que je veux fondamentalement coder le filtrage dans mon modèle. ne doit pas toujours répéter la même méthode de filtrage Where dans chaque requête par rapport à un ensemble d'entités. Plus précisément, j'ai un ensemble d'entités CampaignTypes, et dans le modèle de données que je suis occupé, je ne veux que les types de campagne appartenant à un domaine d'activité donné. Sans le filtrage de niveau inférieur que je cherche, chaque fois que je demande CampaignTypes je vais devoir utiliser CampaignTypes.Where(ct => ct.BusinessArea == BusinessAreas.Outdoor). Comment puis-je éviter ce filtrage répété à court de créer une vue DB et l'utiliser dans mon modèle à la place?Filtrage des ensembles d'entités au niveau du modèle de données

Répondre

0
public IQueryable<CampaignType> getCampaignTypes() 
{ 
    using (var context = new TestEntities()) 
    { 
     var campaignTypes = context.CampaignTypes. 
      Where(ct => ct.BusinessArea == BusinessAreas.Outdoor). 
      AsQueryable<CampaignTypes>(); 
     return campaignTypes; 
    } 
} 

Utiliser le résultat de cette méthode, au lieu d'accéder directement à son contexte. Vous pouvez également modifier votre requête pour retourner une liste, un ensemble, etc. en changeant la méthode "AsQueryable" en "AsList", etc.

+0

juste un conseil: j'ai appris à ne pas utiliser les blocs 'using' comme ça pour les requêtes EF. Cela entrave le chargement paresseux, car lorsqu'un client tente d'accéder à une propriété de navigation qui n'a pas encore été chargée, EF peut essayer de le charger et de trouver le contexte déjà disposé, et vous envoyer une exception grossière. – ProfK

+0

Merci, ProfK. Je suis beaucoup en utilisant le chargement paresseux, donc je n'étais pas au courant de cela. Je vais regarder de plus près ce soir (au travail en ce moment) et déterminer si je devrais supprimer ma réponse ou la modifier. –

1

Vous pouvez ajouter une autre couche (une couche logique) entre le code qui n'a pas besoin de s'inquiéter du filtre et l'ensemble d'entités. Cette couche peut renvoyer un IQuerable ou n'importe quoi et il appliquerait le filtre à l'ensemble d'entités et renverrait les résultats. De cette façon, les autres parties de votre application n'auront pas à s'inquiéter de l'application de ce filtre et c'est toujours une requête unique (dans la plupart des cas) qui s'exécute sur la base de données.

+0

Oui, je l'ai souvent fait auparavant dans ma couche Service, mais j'étais juste curieux quant à toute approche «plus proche du métal». – ProfK

+0

Il peut y avoir. J'éviterais tout ce qui change le code généré, car il sera écrasé dès que vous régénérerez le code. Même dans mes applications simples, j'ai un niveau intermédiaire, même si c'est juste un niveau logique mince, comme c'est habituellement nécessaire à un moment donné. –

1

Vous pouvez créer une autre propriété avec un nom différent dans un autre fichier, en étendant la classe partielle principale de votre modèle.

EDIT:

namespace YourNameSpace 
{ 
    using System.Data.Objects; 

    public partial class SomeModelEntities 
    { 
     public ObjectSet<CampaignType> FilteredCampaignTypes 
     { 
      get 
      { 
       if ((_CampaignType == null)) 
       { 
        _CampaignType = base.CreateObjectSet<CampaignType>("CampaignType"); 
       } 
       return _CampaignType.Where(ct => ct.BusinessArea == BusinessAreas.Outdoor); 
      } 
     } 
    } 
} 
+0

Je ne suis pas sûr de ce que vous entendez par "dupliquer avec un nom différent dans un autre fichier", mais je n'aime pas changer le code généré, surtout au début du développement car je re-générer le modèle assez souvent. – ProfK