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

Obejrzałem tylko kilka webcastów, zanim zacząłem projektować kilka aplikacji Entity Framework. Naprawdę nie przeczytałem zbyt wiele dokumentacji i czuję, że teraz cierpię z tego powodu.

Używam List<T>na moich zajęciach i działa świetnie.

Teraz przeczytałem dokumentację i stwierdza, że ​​powinienem był użyć ICollection<T>. Zmieniłem się na to i nie spowodowało to nawet zmiany kontekstu modelu. Czy to dlatego, że zarówno List<T>i ICollection<T>dziedziczą IEnumerable<T>, i to jest faktycznie wymagane dla EF?

Jeśli jednak tak jest, dlaczego dokumentacja EF nie stwierdza, że IEnumerable<T>zamiast tego wymaga ICollection<T>?

W każdym razie, czy są jakieś wady tego, co zrobiłem, czy powinienem to zmienić?

Entity Framework będzie używać, ICollection<T>ponieważ musi obsługiwać Addoperacje, które nie są częścią IEnumerable<T>interfejsu.

Należy również pamiętać, że były za pomocą ICollection<T>, to były tylko narażając go jako List<T>realizacji. List<T>przynosi wraz z nim IList<T>, ICollection<T>i IEnumerable<T>.

Jeśli chodzi o twoją zmianę, ekspozycja przez interfejs jest dobrym wyborem, mimo że List<T>działa. Interfejs definiuje kontrakt, ale nie implementację. Implementacja może się zmienić. W niektórych przypadkach może to być implementacjaHashSet<T> na przykład . (Nawiasem mówiąc, jest to sposób myślenia, którego możesz użyć nie tylko do Entity Framework. Dobrą praktyką zorientowaną obiektowo jest programowanie w kierunku interfejsu, a nie implementacji. Implementacje mogą się zmieniać i będą się zmieniać).

Wybrali interfejs, który zrobili, ponieważ zapewnia zrozumiałą abstrakcję dla magicznych zapytań wykonywanych przez Entity Framework podczas korzystania z Linq.

Oto różnica między interfejsami:

• IEnumerable<T> jest tylko do odczytu
• Możesz dodawać i usuwać elementy do pliku ICollection<T>
• Możesz zrobić losowy dostęp (według indeksu) do pliku List<T>

Poza tym ICollectioni IEnumerabledobrze mapuj na operacje bazy danych, ponieważ zapytania i dodawanie / usuwanie jednostek to rzeczy, które możesz zrobić w bazie danych.

Losowy dostęp według indeksu również nie jest mapowany, ponieważ musiałbyś mieć istniejący wynik zapytania, aby wykonać iterację, albo każdy losowy dostęp ponownie przeszukiwałby bazę danych. Na co by odwzorowany indeks? Numer wiersza? Nie ma wielu zapytań dotyczących numerów wierszy, które chciałbyś wykonać, i nie jest to w ogóle przydatne przy tworzeniu większych zapytań. Więc po prostu tego nie popierają.

ICollection<T> jest obsługiwany i umożliwia zarówno przeszukiwanie, jak i zmianę danych, więc używaj go.

Powód, dla którego List<T>działa na początku, jest taki, że implementacja EF na końcu zwraca jedną. Ale to jest na końcu twojego łańcucha zapytań, a nie na początku. Dlatego tworzenie właściwości ICollection<T>sprawi, że będzie bardziej oczywiste, że EF tworzy kilka instrukcji SQL i zwraca tylko List<T>na końcu, zamiast wykonywać zapytania dla każdego używanego poziomu Linq.

ICollection różni się od IEnumerable tym, że w rzeczywistości można dodawać elementy do kolekcji, podczas gdy w przypadku IEnumerable nie można. Na przykład w swoich klasach POCO chcesz użyć ICollection, jeśli chcesz zezwolić na dodawanie kolekcji. Uczyń ICollection wirtualną, aby skorzystać również z leniwego ładowania.

Chociaż pytanie zostało opublikowane wiele lat temu, nadal jest aktualne, gdy ktoś szuka tego samego scenariusza.

Niedawno opublikowano [2015] artykuł w CodeProject, który szczegółowo wyjaśnia różnicę i przedstawia ją w formie graficznej z przykładowym kodem . Nie koncentruje się bezpośrednio na EF, ale nadal mam nadzieję, że będzie bardziej pomocny:

List vs IEnumerable vs IQueryable vs ICollection vs IDictionary