ICollection<T> Vs List<T> dans Entity Framework

Question

Je n'ai regardé que quelques webcasts avant de me lancer tête baissée dans la conception de quelques applications Entity Framework. Je n'ai pas vraiment lu beaucoup de documentation et j'ai l'impression d'en souffrir maintenant.

J'ai utilisé List<T> dans mes cours, et ça a très bien marché.

Maintenant, j'ai lu de la documentation et il est dit que j'aurais dû utiliser ICollection<T> . Je l'ai remplacé par celui-ci, et cela n'a même pas provoqué de changement de contexte de modèle. Est-ce parce que les deux List<T> y ICollection<T> hériter de IEnumerable<T> et c'est ce qui est réellement requis pour EF ?

Cependant, si c'est le cas, pourquoi la documentation EF ne précise-t-elle pas qu'il faut IEnumerable<T> au lieu de ICollection<T> ?

Dans tous les cas, y a-t-il des inconvénients à ce que j'ai fait, ou dois-je le changer ?

Answer 1

Entity Framework utiliserait ICollection<T> parce qu'il doit supporter Add les opérations, qui ne font pas partie de la IEnumerable<T> interface.

Notez également que vous étaient en utilisant ICollection<T> vous l'exposiez simplement comme le List<T> mise en œuvre. List<T> apporte avec elle IList<T> , ICollection<T> y IEnumerable<T> .

En ce qui concerne votre changement, l'exposition via l'interface est un bon choix, malgré List<T> de travail. L'interface définit le contrat mais pas l'implémentation. L'implémentation pourrait changement. Dans certains cas, la mise en œuvre pourrait être une HashSet<T> par exemple. (C'est un état d'esprit que vous pourriez utiliser pour autre chose qu'Entity Framework, d'ailleurs. Une bonne pratique orientée objet est de programmer en fonction de l'interface et non de l'implémentation. Les implémentations peuvent et vont changer).

Answer 2

Ils ont choisi l'interface qu'ils ont choisie parce qu'elle donne une abstraction compréhensible sur les requêtes magiques que l'Entity Framework effectue lorsque vous utilisez Linq.

Voici la différence entre les interfaces :

• IEnumerable<T> est en lecture seule
• Vous pouvez ajouter et supprimer des éléments dans une ICollection<T>
• Vous pouvez effectuer un accès aléatoire (par index) à un fichier List<T>

De ceux-là, ICollection y IEnumerable correspondent bien aux opérations de base de données, puisque les requêtes et l'ajout/suppression d'entités sont des choses que l'on peut faire dans une base de données.

L'accès aléatoire par index ne fonctionne pas aussi bien, car il faudrait avoir un résultat de requête existant sur lequel itérer, sinon chaque accès aléatoire interrogerait à nouveau la base de données. De plus, à quoi correspondrait l'index ? Un numéro de rangée ? Il n'y a pas beaucoup de requêtes sur le nombre de lignes que vous voudriez faire, et ce n'est pas du tout utile pour construire des requêtes plus importantes. Ils ne le prennent donc tout simplement pas en charge.

ICollection<T> est prise en charge et vous permettra à la fois d'interroger et de modifier les données, alors utilisez-la.

La raison List<T> fonctionne au départ parce que l'implémentation d'EF finit par en renvoyer un à la fin. Mais c'est à la fin de votre chaîne de requêtes, pas au début. Donc faire en sorte que vos propriétés ICollection<T> rendra plus évident le fait que l'EF crée un tas de SQL et ne renvoie qu'un List<T> à la fin, plutôt que de faire des requêtes pour chaque niveau de Linq que vous utilisez.

Answer 3

ICollection diffère de IEnumerable en ce sens que vous pouvez réellement ajouter des éléments à la collection, alors que ce n'est pas possible avec IEnumerable. Ainsi, dans vos classes POCO, par exemple, vous devez utiliser ICollection si vous avez l'intention de permettre l'ajout d'éléments à la collection. Rendez l'ICollection virtuelle pour bénéficier également du chargement paresseux.

Answer 4

Bien que la question ait été postée il y a plusieurs années, elle reste valable lorsque quelqu'un cherche le même scénario.

Il existe un article récent [2015] de CodeProject qui explique la différence de manière très détaillée et sous forme de représentation graphique avec exemple de code . Il ne s'adresse pas directement à EF, mais j'espère qu'il sera d'une plus grande utilité :

Liste vs IEnumerable vs IQueryable vs ICollection vs IDictionary