Шаблон репозитория - витрина магазина MVC - PullRequest
5 голосов
/ 13 января 2009

Посмотрел витрину магазина MVC и увидел, что IQueryable возвращается из классов репозитория. Хотите знать, если вы не используете LINQ, имеет ли смысл возвращать этот объект? В случае LINQ это имеет смысл из-за отложенного выполнения, поэтому имеет смысл добавить фильтрацию на уровне сервисов, но если вы не используете LINQ, во многих случаях вы захотите фильтровать БД. В этом случае я бы просто добавил методы, которые выполняют фильтрацию в хранилище? Если я это сделаю, действительно ли сервисный уровень полезен?

Ответы [ 3 ]

5 голосов
/ 13 января 2009

Аргументы могут быть сделаны в любом случае, см. Это недавнее сообщение в блоге: Должен ли мой репозиторий представлять IQueryable?

3 голосов
/ 14 января 2009

Материал IQueryable, который Роб Конери добавил в витрину MVC, является инновационным, но ни в коем случае не является нормой, когда речь идет о создании репозиториев. Обычно хранилище отвечает за сопоставление вашего домена с базой данных. Возвращение IQueryable на самом деле не выполняет никакого отображения и полагается на уровень служб для этого. Это имеет свои преимущества и недостатки, но достаточно сказать, что это не единственный способ сделать это.

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

2 голосов
/ 14 января 2009

Проблема, с которой я столкнулся при открытии IQueryable на уровне сервисов, заключается в том, что если вы когда-либо хотели обернуть слой репозитория за веб-сервисом, не нарушая код уровня сервиса, вы не смогли бы, ну, конечно, не используя ADO.NET. Службы данных , но тогда весь ваш код репозитория по существу станет избыточным.

Хотя я думаю, что это может быть довольно продуктивным для небольших приложений, когда вы начинаете смотреть на масштабирование и распространение, оно приносит больше вреда, чем пользы.

...