Является ли шаблон репозитория таким же, как модель поставщика Asp.net?

Question

Начиная с Asp.net 2.0, существует Модель провайдера. В деталях реализации, провайдер - это класс, производный от ProviderBase, который является абстрактным классом, а не интерфейсом, но в любом случае модель провайдера существует, так что у нас может быть другая реализация для замены, просто редактируя web.config. Например, если вы создаете приложение для блога, у вас может быть BlogProvider: ProviderBase, тогда у вас могут быть реализации BlogProvider, такие как: SqlBlogProvider, OracleBlogProvider и даже MockBlogProvider для тестирования.

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

Лично я считаю, что модель поставщика более естественна для меня при реализации. Итак, есть ли разница между ними или это одно и то же с разными именами, данными разными сообществами?

Буду признателен за любые комментарии по этому поводу, Спасибо, Ray.

Answer 1

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

• Цель шаблона Repository состоит в том, чтобы абстрагироваться от особенностей хранилища данных вне приложения.

• Цель модели провайдера состоит в том, чтобы абстрагироваться от особенностей всего вне приложения. Это может быть хранилище данных, но так же часто это какая-то логика.

Например, в нашем приложении у нас есть ContextFactoryProvider, который содержит различные виды логики для определения того, какой ContextFactory использовать. В этом случае нет хранилища данных; это просто логика приложения, которая должна меняться произвольно; Модель провайдера позволяет нам использовать Принцип единой ответственности , чтобы изолировать каждый вид логики в своем собственном классе и легко заменить эту логику.

Answer 2

Я не могу согласиться с Рексом М. Цель шаблона провайдера - предоставить поддержку для настройки через абстрактный интерфейс, тогда как целью шаблона репозитория является предоставление поддержки для абстрагирования деталей недопустимой базы данных.