Пора начинать возвращать IQueryable <T>вместо IList <T>на мой уровень веб-интерфейса / веб-API?

Question

У меня есть многоуровневое приложение, которое запускается с шаблоном хранилища для всего доступа к данным и возвращает IQueryable на уровень служб. Уровень служб, который включает в себя всю бизнес-логику, возвращает IList контроллерам (примечание: я использую ASP.NET MVC для уровня пользовательского интерфейса). Преимущество возврата IQueryable на уровне доступа к данным состоит в том, что он позволяет моим хранилищам быть предельно простыми и откладывать запросы к базе данных. Однако я запускаю запросы к базе данных на своем уровне сервисов, чтобы мои модульные тесты были более надежными, и я не предоставляю контроллерам возможность гибко изменять свои запросы. Однако недавно я столкнулся с несколькими ситуациями, когда откладывание выполнения запросов до контроллеров было бы значительно более производительным, потому что контроллеры должны были сделать некоторые проекции для данных, которые были специфичны для пользовательского интерфейса. Кроме того, с появлением таких вещей, как oData, я начал задаваться вопросом, должны ли конечные точки (например, веб-интерфейс или веб-интерфейс API) работать напрямую с IQueryable. о чем ты думаешь? Не пора ли начать возвращать IQueryable со уровня сервисов на уровень пользовательского интерфейса? Или придерживаться IList?

Эта тема здесь: Чтобы вернуть IQueryable или не вернуть IQueryable похоже, ручается за возврат IList на уровни пользовательского интерфейса, но мне было интересно, если что-то изменится из-за новых технологий и технологий.

Answer 1

Мне нравится, когда это возможно, придерживаться интерфейса IQueryable, единственная проблема в том, что в итоге вы выполняете сложную фильтрацию или повторно запрашиваете по требованию на уровне контроллера, если у вас есть что-то вроде:

//DATA ACCESS
    public IQueryable<T> GetStudents()
    {
    return db.Students;
    }

И в вашем контроллере вы делаете некоторую повторную резкость, потому что ваш клиент хочет отфильтровать некоторые данные этого результата, наверняка у вас будет соблазн сделать это на уровне контроллера:

var result = obj.GetStudents().Where(d=>d...);

и для меня это нормально, но просто представьте, если какой-то другой модуль должен использовать тот же фильтр, вы не можете вызвать его, потому что он находится на уровне контроллера. Так что для меня это баланс между СУХОЙ, гибкостью и масштабируемостью системы. Если вам нужна полностью масштабируемая система, вам нужно будет выполнить несколько или несколько перегрузок для метода GetStudents () и избавиться от повторной резкости на уровне контроллера.