Просматривая некоторые из нашего кода бизнес-логики, я обнаружил, что некоторым методам передаются не выполненные IEnumerables в качестве параметров, таких как этот:
GetDetails(IEnumerable <Entity> item) { // do something with the item }
Теперь код работает нормально как есть, но то, что я вижу, когда нахожусь в отладке, - то, что параметр передает необработанный запрос, а не набор чего-либо. Мне это кажется немного неправильным, так как вы можете использовать базу данных каждый раз, когда этот IEnumberable используется, если запрос направлен на базу данных.
Так что я спрашиваю, передает ли невыполненный IEnumerable в качестве параметра плохую практику метода?
После дополнительного расследования
Я прочитал больше о стеке и нашел этот конкретный вопрос , где Эрик Липперт говорит:
Помните, выражение запроса дает вам объект, который представляет сам запрос. Объект не представляет РЕЗУЛЬТАТЫ запроса, объект представляет запрос. Думайте об этом как о строке запроса SQL, только умнее. Вы запрашиваете запрос о его результатах, и запрос выполняется. Вы спрашиваете снова, запрос выполняется снова; нет никаких гарантий, что результаты совпадают во второй раз, когда вы спрашиваете; с тех пор мир мог измениться
Мне кажется, это говорит о том, что если вы собираетесь использовать не защищенный запрос, такой как IEnumberable, будьте осторожны в том, где вы его используете, и когда вы используете, поскольку вы можете не получить ожидаемых результатов. Но далее в ответах я вижу, что Беван говорит, что он лично делает это:
Параметры методов - используйте IEnumerable, если нет необходимости в более конкретном интерфейсе.
Таким образом, мой вопрос остается в силе: передается неисполненный IEnumerable в качестве параметра плохой практике метода или мне не нужно беспокоиться о том, когда запрашиваются данные, просто о том, что они запрашиваются.