Interface de référentiel - Fonctions disponibles et sortie de filtrage

Question

J'ai un référentiel utilisant LINQ pour modéliser les données qui ont tout un tas de fonctions pour extraire des données. Un moyen très courant d'obtenir des données est pour des choses telles que des listes déroulantes. Ces listes déroulantes peuvent varier. Si nous créons quelque chose nous avons habituellement une liste déroulante avec toutes les entrées d'un certain type , ce qui signifie que j'ai besoin d'une fonction disponible qui filtre par le type d'entité. Nous avons également des pages pour filtrer les données, les listes déroulantes ne contiennent que des entrées qui sont actuellement utilisé, j'ai donc besoin d'un filtre qui nécessite des entrées utilisées. Cela signifie qu'il existe six requêtes différentes pour extraire le même type de données. Le problème avec la définition d'une fonction pour chacun de ceux-ci est qu'il y aurait six fonctions au moins pour chaque type de sortie, le tout dans un seul référentiel. Ça devient très grand, très rapide. Voici quelque chose que je comptais faire:

public IEnumerable<Supplier> ListSuppliers(bool areInUse, bool includeAllOption, int contractTypeID) 
{ 
    if (areInUse && includeAllOption) 
    { 

    } 
    else if (areInUse) 
    { 

    } 
    else if (includeAllOption) 
    { 

    } 
} 

Bien que « areInUse » ne semble pas très anglais amical, je ne suis pas brillant avec nommage. Comme vous pouvez le voir, la logique réside dans ma couche d'accès aux données (référentiel) qui n'est pas conviviale. Je pourrais définir des fonctions séparées, mais comme je le dis, ça grandit assez vite.

Quelqu'un peut-il recommander une bonne solution?

NOTE: J'utilise LINQ pour entités que, je ne l'utilise pas pour interroger. S'il vous plaît ne demandez pas, c'est une contrainte sur le système non spécifié par moi. Si j'avais le choix, j'utiliserais LINQ, mais malheureusement pas.

Answer 1

Demandez à votre méthode prendre une Func<Supplier,bool> qui peut être utilisé dans la clause WHERE afin que vous puissiez passer dans n'importe quel type de filtre que vous voudriez construire. Vous pouvez utiliser un PredicateBuilder pour construire des fonctions complexes arbitraires basées sur des opérations booléennes.

public IEnumerable<Supplier> ListSuppliers(Func<Supplier,bool> filter) 
{ 
    return this.DataContext.Suppliers.Where(filter); 
} 


var filter = PredicateBuilder.False<Supplier>(); 
filter = filter.Or(s => s.IsInUse).Or(s => s.ContractTypeID == 3); 

var suppliers = repository.ListSuppliers(filter); 

Answer 2

Vous pouvez implémenter

IEnumerable<Supplier> GetAllSuppliers() { ... } 

fin puis utilisez LINQ sur la collection retournée. Cela récupèrera tous les fournisseurs de la base de données qui sont ensuite filtrés à l'aide de LINQ.

En supposant que vous utilisez LINQ pour vous SQL pouvez également implémenter

IQueryable<Supplier> GetAllSuppliers() { ... } 

fin puis utilisez LINQ sur la collection retournée. Cela ne récupérera les fournisseurs nécessaires de la base de données que lorsque la collection est énumérée. C'est très puissant et il y a aussi des limites au LINQ que vous pouvez utiliser. Cependant, le plus gros problème est que vous êtes en mesure de forer tout au long de votre couche d'accès aux données et dans la base de données en utilisant LINQ.

Une requête comme

var query = from supplier in repository.GetAllSuppliers() 
      where suppliers.Name.StartsWith("Foo") select supplier; 

tracera dans SQL similaire à quand il est dénombrée

SELECT ... WHERE Name LIKE 'Foo%'