Il est temps de commencer à retourner iQueryable au lieu d'Ilist à ma couche Web UI / API Web?

Question

J'ai une application multicouche qui commence par le modèle de référentiel pour tout accès aux données et il renvoie iQueryable à la couche Services. La couche de services, qui comprend 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 retourner iQueryable dans la couche d'accès aux données est qu'il permet à mes référentiels d'être extrêmement simples et que les requêtes de base de données sont différées. Cependant, je déclenche les requêtes de la base de données dans la couche de mes 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 jusqu'aux contrôleurs aurait été beaucoup plus performant car les contrôleurs devaient faire des projections sur les données spécifiques à l'interface utilisateur. De plus, avec l'émergence de choses comme Odata, je commençais à me demander si les points finaux (par exemple, l'interface utilisateur Web ou les API Web) devraient travailler directement avec iQueryable. Quelles sont vos pensées? Est-il temps de commencer à retourner iQueryable de la couche de services à la couche d'interface utilisateur? Ou rester avec ilist?

Ce fil ici: Pour retourner iQueryableu003CT> ou ne pas retourner iQueryableu003CT>semble se porter garant de retourner Ilist aux couches d'interface utilisateur, mais je me demandais si les choses changent à cause des nouvelles technologies et techniques émergentes.

Answer 1

J'aime m'en tenir à l'interface iQueryable lorsque cela est possible, le seul problème est que lorsque vous finissez par faire du filtrage ou une requête complexe à 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, vous faites des re-sharping parce que votre client souhaite filtrer certaines données de ce résultat, vous serez sûrement tenté de le faire au niveau du contrôleur:

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

Et pour moi, c'est ok, mais il suffit d'imaginer si tout autre module doit utiliser ce même filtre, vous ne pouvez pas l'appeler car c'est au niveau du contrôleur. Donc, pour moi, c'est une chose d'équilibre entre le sec, la flexibilité, et à quel point le système est évolutif. Si vous avez besoin d'un système entièrement évolutif, vous devrez effectuer certaines ou plusieurs surcharges pour obtenir la méthode GetStudents () et vous débarrasser de toute re-sharping au niveau du contrôleur.