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

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

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

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

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


repository-pattern design-patterns provider-model
person Ray    schedule 08.03.2009    source источник
comment
Аналогичное объяснение принятого ответа ниже forums.asp. нетто/т/   -  person Ray    schedule 18.05.2014

Ответы (2)


arrow_upward
15
arrow_downward

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

  • Цель шаблона репозитория — абстрагировать специфику репозитория данных от приложения.

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

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

person Rex M    schedule 08.03.2009
comment
Также стоит упомянуть, что полезно внедрять репозитории в провайдеров. Таким образом, у вас есть гибкость для различных стратегий провайдера с дополнительным преимуществом, заключающимся в том, что провайдер не привязывается к конкретному репозиторию. В 9 из 10 раз я оказываюсь и в репозиториях, и в провайдерах. - person EightyOne Unite; 26.09.2011

arrow_upward
1
arrow_downward

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

person Ashraf Alam    schedule 18.03.2009