Время начать возвращать iqueryable вместо илиста на мой веб -интерфейс / веб -API -уровень?

Question

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

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

Answer 1

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

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

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

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

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