Нужно ли нам использовать шаблон репозитория при работе в ASP.NET MVC с решениями ORM?

Ответ будет нет , если вам не нужно иметь возможность переключать ORM или иметь возможность тестировать любой класс, имеющий зависимость от вашей ORM / базы данных.

Если вы хотите иметь возможность переключать ORM или иметь возможность легко тестировать свои классы, которые используют уровень базы данных: Да, вам нужен репозиторий (со спецификацией интерфейса).

Вы также можете переключиться на хранилище памяти (которое я делаю в своих модульных тестах), файл XML или что-то еще, если вы используете шаблон хранилища.

Обновление

Проблема с большинством реализаций шаблонов репозиториев, которые вы можете найти с помощью Googling, заключается в том, что они не очень хорошо работают в производстве. У них нет опций для ограничения результата (подкачки страниц) и упорядочивания результата, что довольно удивительно.

Шаблон репозитория достигает своей славы, когда он объединяется с реализацией UnitOfWork и имеет поддержку шаблона спецификации.

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

Обновление 2

Репозиторий - это гораздо больше, чем просто абстрактный доступ к базе данных, как это может сделать ORM. Обычная реализация репозитория должна обрабатывать все агрегатные объекты (например, Order и OrderLine). Но обрабатывая их в одном классе хранилища, вы всегда можете убедиться, что они построены правильно.

Но, эй, вы говорите: это автоматически делается для меня ORM. Ну да и нет. Если вы создаете сайт, вы, скорее всего, захотите изменить только одну строку заказа. Получаете ли вы полный заказ, перебираете его, чтобы найти заказ, а затем добавляете его в представление?

Тем самым вы вводите логику в свой контроллер, который там не принадлежит. Как вы делаете это, когда веб-сервис хочет то же самое? Дублировать ваш код?

С помощью ORM довольно легко получить любую сущность из любого места myOrm.Fetch<User>(user => user.Id == 1), изменить ее и затем сохранить. Это может быть очень удобно, но также добавляет запахи кода, поскольку вы дублируете код и не можете контролировать, как создаются объекты, если они получили действительное состояние или правильные ассоциации.

Следующее, что приходит на ум, это то, что вы можете иметь возможность подписаться на такие события, как «Создано», «Обновлено» и «Удалено» централизованно. Это легко, если у вас есть хранилище.

Для меня ORM предоставляет способ сопоставления классов с таблицами и ничего более. Мне все еще нравится оборачивать их в репозитории, чтобы иметь возможность контролировать их и получать единую точку модификации.

Я думаю, что это имеет смысл, только если вы хотите снизить уровень зависимости. В резюме вы можете иметь IPostRepository в своем пакете инфраструктуры и несколько независимых реализаций этого интерфейса, построенных поверх EF, NH или чего-то еще. Это полезно для TDD.

На практике сеанс NH (и контекст EF) реализует нечто вроде шаблона «Единица работы». Кроме того, с NH и шаблоном Repository вы можете получить много ошибок и архитектурных проблем.

Например, сущность NH может быть сохранена в обход вашей реализации репозитория. Вы можете получить его из сеанса (Repository.Load), изменить одно из его свойств и вызвать session.Flush (например, в конце запроса, потому что шаблон репозитория не предполагает сброса) - и ваши изменения будут успешно обработаны в дБ.