Il est temps de commencer à retourner IQueryable <T> au lieu de IList <T> à mon API Web UI/Web couche?

Question

J'ai une application multi-couche qui commence par le modèle référentiel pour tous les accès aux données et renvoie IQueryable à la couche de services. La couche Services, qui inclut toute la logique métier, renvoie IList aux contrôleurs (remarque: j'utilise ASP.NET MVC pour la couche d'interface utilisateur). L'avantage de renvoyer IQueryable dans la couche d'accès aux données est qu'il permet à mes référentiels d'être extrêmement simples et de différer les requêtes de la base de données. Cependant, je déclenche les requêtes de base de données dans ma couche services afin que mes tests unitaires soient plus fiables et que je ne donne pas de flexibilité aux contrôleurs pour remodeler mes requêtes. Cependant, j'ai récemment rencontré plusieurs situations où le report de l'exécution des requêtes vers le bas aux contrôleurs aurait été beaucoup plus performant parce que les contrôleurs ont dû faire des projections sur les données qui étaient spécifiques UI. De plus, avec l'émergence de choses comme oData, je commençais à me demander si les points de terminaison (par exemple, l'interface web ou l'API web) devraient fonctionner directement avec IQueryable. Quelles sont vos pensées? Est-il temps de retourner IQueryable de la couche services à la couche UI? Ou coller avec IList?

Ce fil ici: To return IQueryable<T> or not return IQueryable<T> semble se porter garant pour le retour IList aux couches de l'interface utilisateur, mais je me demandais si les choses changent à cause des nouvelles technologies émergentes et techniques.

Answer 1

J'aime coller avec l'interface IQueryable lorsque cela est possible, le seul problème est quand vous finissez par faire un filtrage complexe ou re-requête sur la demande au niveau du contrôleur, si vous avez quelque chose comme:

//DATA ACCESS 
    public IQueryable<T> GetStudents() 
    { 
    return db.Students; 
    } 

et dans votre contrôleur que vous faites une re-sharping parce que votre client souhaitez filtrer certaines données de ce résultat, sûrement vous serez tenté de le faire au niveau du contrôleur:

var result = obj.GetStudents().Where(d=>d...); 

et pour moi son ok, mais juste l'imagerie si un autre module doit utiliser ce même filte r, vous ne pouvez pas l'appeler parce que c'est au niveau du contrôleur. Donc, pour moi, c'est une question d'équilibre entre DRY, flexibilité, et comment le système est évolutif. Si vous avez besoin d'un système entièrement évolutif, vous aurez besoin de faire quelques ou plusieurs à la méthode GetStudents les surcharges() et se débarrasser de tout re-sharping au niveau du contrôleur.