Мне нравится передавать IQueryable в мои контроллеры, потому что мне не нужно создавать хромые методы подкачки и сортировки в каждом отдельном методе и интерфейсе DAO на протяжении всей жизни моих приложений.
GetCustomersByLastname( string lastname )
быстро становится
GetCustomersByLastname( string lastname, string sortcolumn, int pagesize, int page )
Снова и снова и снова и снова. Блек!
С помощью IQueryable вы можете использовать функции подкачки и сортировки приложений ортогональными способами, например, используя преимущества проекта IPagedList. Возвращение IQueryable также дает вам легкий доступ к общему объекту .Count () без дополнительных извращений вашего уровня данных.
@ Аргумент Роберта о IQueryable, равном жирным контроллерам, очень шаток. Fat-контроллер будет похож на раздутые страницы .aspx.cs прошлого. Если все, что вы делаете - это подключаетесь к вашему DAL, а затем отправляете результаты, не получая «жирности» от вашей техники запросов, вы получаете ее, вкладывая много логики в один класс. Вы не получите Fat Controller из-за ваших методов доступа к данным, если не начнете прокручивать протоколирование, уведомления и другие ортогональные проблемы внутри.
public ActionResult Detail( string searchTerm )
{
var model = MyDAL.MyObjects( searchTerm );
}
против:
public ActionResult Detail( string searchTerm )
{
var model = MyDAL.MyObjects.Where( x => x.Name == searchTerm );
}
Я не вижу существенной разницы.
@ Ответ Марка Симанна одинаково шаток. Конечно, вы можете изменить весь слой данных в середине проекта, но это будет сложная катастрофа, независимо от того, насколько вы абстрагированы. В качестве примера он использует переход с Linq2Sql на табличное хранилище Windows Azure. СУБД в хранилище ключей / значений? И болевая точка - ваша реализация репозитория? Переход от RDBMS к хранилищу ключей / значений будет сумасшествием, которое будет ужасно, несмотря ни на что.
Марк также приводит аргумент в пользу доменного дизайна. Это тип системы вашего здания. Достаточно ли «доменных», а не чистых сценариев CRUD, которые делают этот подход полезным? Если нет, то зачем?
Использование LINQ и интерфейса IQueryable в любом случае избавляет вас от необходимости переключать слои данных. Если вы переключаетесь между ORM, которые поддерживают LINQ и IQueryableProvider (я думаю, это название), то об этом изменении заботится только нижестоящий код. Теперь ваши контроллеры будут переключаться между большинством ORM, представленных на рынке.