Pour revenir IQueryable<T> ou de ne pas retourner IQueryable<T>

J'ai un référentiel de classe qui encapsule mon LINQ to SQL Contexte de Données. Le référentiel de la classe est un métier de classe qui contient toutes les données de niveau logique (et la mise en cache et tel).

Voici mon v1 de mon repo interface.

public interface ILocationRepository
{
    IList<Location> FindAll();
    IList<Location> FindForState(State state);
    IList<Location> FindForPostCode(string postCode);
}

Mais pour gérer la pagination pour FindAll, je suis débats à savoir si ou de ne pas exposer IQueryable<ILocation> au lieu de IList de simplifier l'interface pour des circonstances telles que la pagination.

Quels sont les avantages et les inconvénients d'exposer IQueryable à partir des données repo?

Toute aide est très appréciée.

Comment sur l'utilisation de IEnumerable<T> dans le référentiel de l'interface?
Je ne suis pas pour l'utilisation de IEnumerable<T> dans le Référentiel ou BLL, car il peut affecter les performances dans le cas où vous ne payez pas l'attention, et de nombreuses boucles foreach de la même liste, dans ce cas, vous pourrez appeler GetEnumerator() de nombreuses fois.

InformationsquelleAutor CVertex | 2009-04-05

.net c#iqueryable linq-to-sql

90

Les pros; la composabilité:
- les appelants peuvent ajouter des filtres
- les appelants peuvent ajouter la pagination
- les appelants peuvent ajouter un tri
- etc
Les inconvénients; la non-réfutabilité:
- Votre référentiel n'est plus correctement unité vérifiable; vous ne pouvez pas compter sur un: il travaille, b: ce il n';
  - l'appelant pourrait ajouter un non-traduisible fonction (c'est à dire pas de TSQL de cartographie, des pauses au moment de l'exécution)
  - l'appelant pouvait ajouter un filtre/tri qui le fait travailler comme un chien
- Depuis les appelants s'attendre à IQueryable<T> être composable, il les règles de non-composable implémentations ou il vous oblige à écrire votre propre fournisseur de requêtes pour eux
- cela signifie que vous ne pouvez pas optimiser /profil de la DAL
Pour la stabilité, j'ai pris pas exposer IQueryable<T> ou Expression<...> sur mon dépôts. Cela signifie que je sais comment le référentiel de se comporter, et mes couches supérieures pouvez utiliser les objets fantaisie, sans se soucier de "l'référentiel à l'appui de cette?" (forcer les tests d'intégration).

- Je encore utiliser IQueryable<T> etc à l'intérieur de le référentiel - mais pas sur la limite. J'ai posté quelques plus d'idées sur ce thème ici. Il est tout aussi facile de mettre les paramètres de pagination sur le référentiel de l'interface. Vous pouvez même utiliser des méthodes d'extension (sur l'interface) pour ajouter facultatif paramètres de pagination, de sorte que les classes concrètes ont seulement 1 méthode à mettre en œuvre, mais il y a peut être 2 ou 3 surcharges disponible à l'appelant.
- que voulez-vous dire à propos de IEnumerable<T> pour le dépôt des méthodes?
- Si elle est utilisée de manière appropriée, IEnumerable<T> serait OK - mais surtout pour les gros volumes de données. Pour des requêtes régulières, je préfère un ensemble fermé (tableau/liste/etc). En particulier, je suis en utilisant MVC pour le moment, et je veux le controller récupérer toutes les données, pas le différer jusqu'à ce que le point de vue - d'autre vous ne pouvez pas entièrement test...
- ...le contrôleur, que vous n'avez pas réellement prouvé l'extraction de données (depuis IEnumerable<T> est généralement utilisé avec l'exécution différée). Si le repo retourne IList<T> (ou similaire), vous savoir vous avez obtenu les données.
- et.. quel est le problème avec la mise à feu d'une executin au sein de l'unité de test? Ex.: Assert.IsTrue(result.Any())
- Avec IQueryable<T>, que les changements de la requête réelle. Avec IEnumerable<T>, et un peu moins - mais encore: l'obtention de données est de la responsabilité du contrôleur, pas de la vue.
- Sur votre dernier relevé sur option des paramètres de pagination, et 2 ou 3 surcharges disponible à l'appelant, pourriez-vous nous orienter vers un article à ce sujet?
- Juste pour ajouter à cela, le retour IQueryable semble briser la totalité de l'idée de disposer d'un référentiel serait-il pas? Vous êtes à la création d'une architecture de couture qui dépend d'une banque de données qui implémente correctement IQueryable. Si pour quelque raison vous avez eu à passer à un autre modèle de stockage qui ne joue pas gentil avec IQueryable à tous? Un exemple serait un projet que j'ai porté à exécuter sur Mono (tout à l'arrière. J'ai dû utiliser de la vieille école ADO. Si mon repos avait utilisé IQueryable j'aurais dû re-facteur de la logique de l'application, car il aurait été dans la construction de mes requêtes LINQ.
- Je ne suis pas en désaccord
- 3 ans de retard, mais je préfère exposer IQueryable<T> pour aussi longtemps que possible. Le contrôleur peut filtrer ce qu'il a besoin de plus et la vue peut filtrer plus loin si besoin, ou même réduire le champs il a besoin de ce que le contrôleur fournit. Peut-être que je n'ai pas besoin de tous les champs de la classe Personne dans la vue. Pourquoi voudrais-je le référentiel pour récupérer tous à mettre dans une classe de Personne quand je ne voulais vraiment leur nom? Comme pour les essais, dépend de ce que vous essayez de tester. Vous pouvez toujours tester le référentiel de données de retour demandé.
- Faire un OrderBy/Prendre/Sauter dans le point de vue est toujours possible, même sur un IList, il est juste beaucoup moins efficace, de sorte qu'il n'a pas vraiment d'aide de l'unité de test de la vue, mais à moins que vous écrivez des tests unitaires pour votre point de vue, il n'a jamais testé eux de toute façon.
- IQueryable n'empêche pas de test du tout.
- il n'empêche pas la intégration tests, mais il absolument n'est pas adapté pour unité tests utilisant des choses comme se moque ou AsQueryable(); de par la nature de IQueryable<T>, l'appelant ne peut pas savoir les requêtes qui seront pris en charge, et tout en mémoire maquette / etc va utiliser le plus généreux de la mise en œuvre, c'est à dire LINQ-to-Objets (ce qui est présent plus permissives que les choses comme les EF ou LINQ-to-SQL, etc)
- .AsQueryable() est inutile, mais il n'y a rien qui vous empêche de vérifier l'Expression des arbres utilisés dans les prédicats et ainsi de suite. IQueryable et la composabilité des requêtes de loin le poids de l'limitations de IEnumerable/IList/ICollection base de repository. (Qui eux-mêmes ont des problèmes similaires avec les tests unitaires que vous n'êtes pas à l'examen de la demande est en fonctionnement.
- la vérification des arbres d'expression est utile si vous êtes à la vérification de la compilation ou de l'Queryable les méthodes d'extension. Habituellement, cependant, ce n'est pas un test utile.
InformationsquelleAutor Marc Gravell
7

, Comme l'a mentionné à la réponse précédente, exposant IQueryable donne accès aux appelants de jouer avec IQueryable lui-même, qui est ou peut devenir dangereux.

De l'encapsulation de la logique métier de première responsabilité est de maintenir l'intégrité de votre base de données.

Vous pouvez continuer à exposer IList et peut-être modifier vos paramètres suivants, c'est la façon dont nous sommes en train de faire...
```
public interface ILocationRepository
{
    IList<Location> FindAll(int start, int size);
    IList<Location> FindForState(State state, int start, int size);
    IList<Location> FindForPostCode(string postCode, int start, int size);
}
```
si taille == -1 alors retour tous...

Autre façon...

Si vous voulez encore de retour IQueryable, alors vous pouvez retourner IQueryable de la Liste à l'intérieur de vos fonctions.. par exemple...
```
public class MyRepository
{
    IQueryable<Location> FindAll()
    {
        List<Location> myLocations = ....;
        return myLocations.AsQueryable<Location>;
        //here Query can only be applied on this
        //subset, not directly to the database
    }
}
```
Première méthode a un avantage sur la mémoire, parce que vous reviendra moins de données à la place de tous.
- Ce n'est pas très élégante. De cette façon, CVertex devez ajouter ces paramètres (démarrer, taille) pour CHAQUE dépôt de la méthode qu'il crée - très mauvaise programmation de la pratique.
- Eh bien c'est mieux que d'exposer Base de Données de l'Interface, qui peut les modifier et de les gâter vos données.
- Seulement besoin d'ajouter les paramètres de pagination où ils sont effectivement utilisés. Et s'ils sont utilisés, ce n'est pas un gaspillage d'efforts.
- Aïe, votre deuxième méthode serait une app killer! Il serait tirer tous les résultats dans la mémoire et d'effectuer LINQ sur eux. Je n'ai jamais trouvé un vraiment de raison d'utiliser AsQueryable pour être honnête. Je ne suis même pas sûr de savoir pourquoi il existe. Il ne va pas soudainement tourner votre Liste dans un IQueryable et vous permettent de construire des arbres d'expression qui sont envoyés à votre magasin de données, alors quel est le point?
- Je suis d'accord, j'ai écrit ce long temps de retour avec peu de connaissances de la façon dont EF travaillé, je n'ai pas moyen de charger toutes les données en mémoire.
- est utile lorsque vous obtenez un non-générique IEnumerable à partir d'un héritage de l'API.
- Ah, je suppose que ça a du sens.
InformationsquelleAutor Akash Kava
2

Je recommande d'utiliser IEnumerable au lieu de IList, avec elle, vous aurez plus de flexibilité.

De cette façon vous serez en mesure d'obtenir à partir de Db seule la partie des données qui vous va vraiment utiliser sans travail supplémentaire accompli dans votre référentiel.

Exemple:
```
//Repository
public interface IRepository
{
    IEnumerable<Location> GetLocations();
}

//Controller
public ActionResult Locations(int? page)
{
    return View(repository.GetLocations().AsPagination(page ?? 1, 10);
}
```
Qui est super propre et simple.
- Pourquoi? Quels sont les compromis?
- IList<Location> FindAll() n'est pas très efficace si vous allez à l'affichage d'une liste paginée à l'utilisateur (disons 1000 lignes sont extraites de db, mais seulement 10 d'entre eux seront affichés). Avec IQueryable vous n'aurez pas ce genre de question.
- BTW, si vous allez mettre en œuvre les fonctionnalités de pagination prendre un coup d'oeil à l'assistant existante classs dans MvcContrib = codeplex.com/mvccontrib (MvcContrib.La Pagination de l'espace de noms)
- Cette exigence pourrait être exposé aussi facilement sur le référentiel de l'interface...
- Je suis fan de créer détaillé référentiel de méthodes. par exemple,GetRecords(int page, int itemsPerPage). Plutôt que de passer à la pagination off pour les contrôleurs.
InformationsquelleAutor Konstantin Tarkus

Vous devez vous connecter pour publier un commentaire.

Exemple: