Зачем ты меня заставляешь повторяться? Я всё сказал, но ты игнорируешь.

Семантически IEnumerable -- это бесконечная ленивая последовательность. За ней легко может быть генератор (yield), ленивая выборка из БД или из внешнего сервиса. Каждый повторный проход по такой последовательности может легко приводить к повторным вычислениям, повторным запросам к БД или к внешнему сервису. Плюс, повторный проход может абсолютно легально по интерфейсу и семантике возвращать разный результат и разное количество.

Массив, IReadOnlyCollection/List -- это семантически неизменная материальная коллекция. По ней можно безопасно ходить сколько угодно раз. У неё есть заранее известное количество.

Уместно принимать на вход IEnumerable, когда мы знаем, что данные будут обработаны одним проходом. Возвращать также уместно в том случае, когда это не обязательно коллекция, а что угодно. Любая реализация.

Если ты не знаешь когда тебе применять IEnumerable, значит есть проблемы с пониманием того, как писать хорошо сопровождаемый, ясный, правильный код, в котором возможность выстрелить себе в ногу сведены к минимуму.




Я вроде всё достаточно ясно пояснил. ДТО-шка это материализованный, конечный результат. Так как он используется для сериализации/десериализации, то коллекции в нём должны быть коллекциями, а не ленивыми последовательностями.

Да ты просто не читал, что я писал.

Нельзя "ничего не иметь против", каждый инструмент нужно применять по назначению.
Просто за IEnumerable новички, любители видят коллекцию -- но это не так.

Как только придёт осознание, что IEnumerable это не коллекция, а ленивая бесконечная последовательность, то всё станет на свои места.

Тогда будет понятно когда применять IEnumerable, а когда интерфейсы коллекций или массивы.

Если такого понимания нет, то нужно прежде к нему прийти, а потом дискутировать дальше.

Его не надо реализовывать. Здесь, например, ты явно говоришь, что возвращаешь материализованную коллекцию, значит от FTP можно отцепиться, а не держать коннект.

Бла, ну разве это не очевидно? )))

Я как бы не против. Но свои пояснения, довольно конкретные я дал. Никого принуждать ни к чему не собираюсь.

fkthat,

Я тебе пример факапа приведу, как раз из самого свежего на моих проектах.
На одном проекте, который достался по наследству, джамшуты в ДТОшках юзали IEnumerable.
Всё вроде работало, а потом после очередной доработки всё накрылось п..дой.

Что сделали? В одном методе добавили кеширование результата, ДТО-шки, в которой был IEnumerable. А заполнялся он лениво с вычислениями, походами в две разные БД.

Разработчик сделал всё правильно. Видит, в ДТО-шке IEnumerable, сервис возвращает IEnumerable, ну и присвоил, по типам всё ок. Ругать его за это нельзя.

Ругать надо криворуких рукожопов, которые не могли использовать массив или интерфейс коллекции в ДТО, тогда разработчик физически должен был материлизовать полученный IEnumerable.

Ну перебери мне это:

Ни один интерфейс не даёт 100% гарантии реализации. Я тебе и IEnumerable могу реализовать, которые будет делать что угодно, и плеваться исключениями в зависимости от фазы луны.

Сам интерфейс -- это контракт. И да, контракт IReadOnlyCollection обещает, что никто не будет коллекцию менять, и что она неизменна.

А кривая реализация, это уже либо саботаж, либо рукожопство.

Кешировали ДТО-шку. Всё абсолютно легально. Нет, ругать его никто не собирался -- в команде это признали, не его косяк.



Represents a strongly-typed, read-only collection of elements.

Обещает. И по описанию, и по названию.



Вообще не понял в чём посыл.




Не обязательно, всё верно. Передавая интерфейс IReadOnly -- гарантируется, что по ссылке на интерфейс коллекция не будет ни кем не изменена. Но владелец конечно изменить её может, это по сути косяк FCL, так как эти интерфейсы были добавлены слишком поздно.