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

Question

Я смотрел только несколько веб-трансляций, прежде чем приступил к разработке нескольких приложений Entity Framework.Я действительно не читал так много документации, и я чувствую, что сейчас страдаю из-за этого.

Я использовал List<T> в своих классах, и это отлично сработало.Я прочитал некоторую документацию, и в ней говорится, что я должен был использовать ICollection<T>.Я изменился на это, и это даже не вызвало изменения контекста модели.Это потому, что и List<T>, и ICollection<T> наследуют IEnumerable<T>, и именно это действительно требуется для EF?

Однако, если это так, почему в документации EF не указано, чтотребует IEnumerable<T> вместо ICollection<T>?

В любом случае, есть ли какие-либо недостатки в том, что я сделал, или я должен изменить это?

Answer 1

Entity Framework будет использовать ICollection<T>, поскольку он должен поддерживать Add операции, которые не являются частью интерфейса IEnumerable<T>.

Также обратите внимание, что вы были , используя ICollection<T>, вы просто выставили его как реализацию List<T>.List<T> влечет за собой IList<T>, ICollection<T> и IEnumerable<T>.

Что касается ваших изменений, экспонирование через интерфейс является хорошим выбором, несмотря на то, что List<T> работает.Интерфейс определяет контракт, но не реализацию.Реализация может измениться.В некоторых случаях, возможно, реализация могла бы быть, например, HashSet<T>.(Кстати, это образ мышления, который вы можете использовать не только для Entity Framework. Хорошая объектно-ориентированная практика - программировать в направлении интерфейса, а не реализации. Реализации могут и будут меняться.)

Answer 2

Они выбрали интерфейс, который сделали, потому что он дает понятную абстракцию над магическими запросами, которые Entity Framework выполняет при использовании Linq.

Вот разница между интерфейсами:

• IEnumerable<T> только для чтения
• Вы можете добавлять и удалять элементы в ICollection<T>
• Вы можете сделать произвольный доступ (по индексу) к List<T>

Из них ICollection и IEnumerable хорошо отображаются на операции базы данных, поскольку запросы и добавление / удаление объектов - это то, что вы можете делать в БД.

Произвольный доступ по индексу также не отображается, так как вам нужно будет иметь существующий результат запроса для повторения, или каждый случайный доступ будет запрашивать базу данных снова. Кроме того, на что будет привязан индекс? Номер строки? Существует не так много запросов с номерами строк, которые вы бы хотели выполнить, и это вовсе не полезно при создании запросов большего размера. Так что они просто не поддерживают это.

ICollection<T> поддерживается и позволит вам как запрашивать, так и изменять данные, поэтому используйте это.

Причина, по которой List<T> работает с самого начала, заключается в том, что реализация EF в конечном итоге возвращает одну в конце. Но это в конце цепочки запросов, а не в начале. Таким образом, выполнение ваших свойств ICollection<T> сделает более очевидным, что EF создает группу SQL и возвращает только List<T> в конце, а не выполняет запросы для каждого уровня Linq, который вы используете.

Answer 3

ICollection отличается от IEnumerable тем, что вы действительно можете добавлять элементы в коллекцию, тогда как с IEnumerable вы не можете. Так, например, в ваших классах POCO вы хотите использовать ICollection, если вы хотите разрешить добавление коллекции в. Сделайте ICollection виртуальной, чтобы извлечь выгоду из отложенной загрузки.

Answer 4

Хотя вопрос был опубликован много лет назад, он все еще действителен, когда кто-то ищет тот же сценарий.

В недавней [2015] статье CodeProject объясняется разница во многих деталях и графическом представлении образец кода .Он не ориентирован непосредственно на EF, но все же надеется, что он будет более полезен:

Список против IEnumerable против IQueryable против ICollection против IDictionary