Хорошо ли использовать IEnumerable всю область применения, когда вам не нужно добавлять или удалять вещи, а перечислять их только?
Боковой вопрос: возникли ли у вас проблемы с возвратом IEnumerable<T> из службы WCF? Может ли это вызвать проблемы для клиентских приложений? В конце концов, я думаю, что будет сериализован в массив.
Я обычно возвращаю IEnumerable<T>, когда хочу намекнуть вызывающему, что реализация может использовать ленивую оценку. В противном случае я обычно возвращаю IList<T> или ICollection<T> и реализую как ReadOnlyCollection<T>, если результат должен быть только для чтения.
Ленивая оценка может быть важным соображением: если ваша реализация может вызвать исключение, это не будет выбрано, пока вызывающий абонент не начнет перечислять результат. Вернув IList<T> или ICollection<T>, вы гарантируете, что любое исключение будет выбрано в момент, когда вызывается метод.
В случае метода WCF возврат IEnumerable<T> из метода, который использует ленивую оценку, означает, что любое исключение не может быть выбрано до тех пор, пока ваш ответ не будет сериализован - это даст вам меньше возможностей обрабатывать его на стороне сервера.
У меня нет источников Good Practices, но я часто склонен полагаться на List для моих коллекций, и он реализует IEnumerable, но я передаю его как List, а не IEnumerable, если мне нужно, чтобы он был доступен только для чтения я скорее передаю ReadOnlyCollection..
Мне не нравится возвращать или принимать IList<T> или List<T>, потому что они подразумевают возможность изменения коллекции.
Поэтому предпочитайте возвращать T[] в виде коллекции фиксированного размера. Кроме того, массив можно легко сопоставить с любой другой платформой, платформой и т.д.
И предпочитаем принимать IEnumerable<T>, чтобы подчеркнуть, что метод будет перечислять эту коллекцию.