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

Question

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

Спасибо!

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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