Могу ли я использовать это в модели репозитория?

Question

Я работаю над проектом, использующим ASP.NET MVC и модель хранилища. У меня есть классы репозитория и сервисы, которые используют эти классы репозитория. Мой вопрос: правильно ли возвращать IQueryable из моего класса репозитория, а затем использовать «.Where» и «.OrderBy» в Сервисе для генерации Списка? Если да, то это лучшая практика?

Спасибо!

Answer 1

Для начала: здесь нет «правильного» или «неправильного». Это просто вопрос того, что лучше всего работает для вас и системы, которую вы строите. Например, Роб Конери сделал пример приложения ASP.NET под названием Storefront с точным шаблоном, который вы описываете, и это вызвало большую войну пламени. Большая часть обсуждения развивалась вокруг шаблона репозитория, который считается «оригинальным», как его описывает Эрик Эванс в своей книге « Домен-управляемый дизайн », и который описывает интерфейс репозитория как тот, который принимает и / или возвращает фактические экземпляры (списков экземпляров), а не какой-либо интерфейс запроса.

Так много для теории. Что выбрать для вашей системы? Причина, по которой я не выбрал бы прямой путь IQueryable, заключается в том, что он фактически пропускает немного моей стратегии персистентности на уровень клиента (в данном случае это уровень обслуживания). Поскольку в первую очередь имеет смысл возвращать IQueryable, если вы извлекаете объекты из базы данных, используя LINQ для [метод доступа к базе данных (например, SQL, Entities, ...)]. Только тогда .Where или .OrderBy будут оптимизировать результат вашего запроса. Это, очевидно, не имеет смысла, если вы используете некоторый код кода доступа к базе данных, который получает полный список, который вы затем выставляете из репозитория, используя LINQ to Objects. Вкратце: вы связываете свой клиентский уровень с используемой вами стратегией доступа к базе данных на основе LINQ.

Будучи немного пуристом, я бы предпочел не показывать эту связь с LINQ из своего хранилища, и я бы предпочел предлагать критерии «где» и «порядок» через параметры операций хранилища. Я могу выполнить всю поисковую оптимизацию в хранилище и вернуть аккуратный чистый набор доменных объектов.

Итак, в конце концов, все сводится к следующему: все, что работает лучше для вас, в порядке.

Answer 2

Да, я очень доволен, что репозиторий возвращает IQueryable, но с одной оговоркой: некоторые функции Linq доступны не для всех провайдеров. Например, методы Single / SingleOrDefault недоступны в Linq to Entities. Поэтому вашему сервисному уровню, возможно, придется перепрыгнуть через несколько циклов, в зависимости от того, какая конкретная реализация вашего репозитория используется.

Обычно я помещаю интерфейс классов репозитория на уровне домена, а фактические реализации - на уровне службы.

Answer 3

Я не понимаю, почему это было бы проблемой. Если вы хотите стать более конкретным в данных, которые вы будете получать на уровне обслуживания, это означает, что между приложением и базой данных будет передаваться меньше данных, что означает более высокую эффективность. Это означает, что вы также будете выполнять отложенную загрузку или получать данные, когда они вам абсолютно необходимы. Учитывая безгражданство в Интернете, это хорошо. Вы не хотите получать все данные в случае, если вы могли бы использовать их.

Другими словами, нет смысла получать весь список пользователей, просто выбрать того, кого зовут «Джеколантерн».

Лучший способ думать об этом так: если вы решите перейти с MSSQL на MySQL завтра, придется ли вам копировать бизнес-логику? Если это так, то вы используете свой репозиторий неправильно.