É o padrão de repositório o mesmo que o Provedor de Asp.net modelo?

Question

Desde Asp.net 2.0, há o modelo de provedor. No detalhe de implementação, um fornecedor é classe derivada de ProviderBase que é uma classe abstrata, em vez de uma interface, mas de qualquer maneira o provedor Modelo está lá para que possamos ter aplicação diferente para swap no fora apenas editando o web.config. Por exemplo, se você criar um aplicativo blog, você pode ter um BlogProvider: ProviderBase, então você pode ter implementações de BlogProvider como:. SqlBlogProvider, OracleBlogProvider e até mesmo MockBlogProvider para testar

Agora, Padrão Repositório está ficando popular, e eu sinto que é para satisfazer a mesma necessidade, embora no detalhe de implementação, você normalmente usar interfaces, de modo IBlogProvider, e você injetar diferentes implementações através de construtores em vez de propriedades, mas essencialmente, não vejo a diferença de que estes 2 padrões nos deu.

Pessoalmente, sinto Provider modelo é mais natural para mim na implementação. Assim, há uma diferença entre eles ou eles são apenas a mesma coisa com diferentes nomes dados por diferentes comunidades?

Eu apreciaria quaisquer comentários sobre isso, Obrigado, Ray.

Answer 1

O Repositório e padrões Provedor sobrepõem, mas eles não formalmente descrever a mesma coisa. Eu quase diria o Repositório é um subconjunto do Provedor. Na prática, eu acho que o padrão Repository era a cargo de uma necessidade específica - abstraindo repositórios - e evoluiu na comunidade em um padrão de abstração mais genérico. A esse respeito, eles passaram a ser diferentes termos que descrevem o mesmo conceito. No entanto, a partir das definições originais, eles são diferentes em escopo:

• O objetivo do padrão Repository é abstrair as especificidades de um repositório de dados longe da aplicação.

• O propósito do modelo de Provedor é abstrair as especificidades do qualquer longe da aplicação. Este pode ser um repositório de dados, mas é apenas tão frequentemente algum tipo de lógica.

Por exemplo, em nossa aplicação temos um ContextFactoryProvider, que contém diferentes tipos de lógica para determinar quais ContextFactory para uso. Não há repositório de dados, neste caso; é puramente lógica de aplicação que precisa mudar arbitrariamente; o modelo de provedor permite-nos usar a Individual de Responsabilidade Princípio para isolar cada tipo de lógica em sua própria classe e swap que lógica facilmente.

Answer 2

Eu não posso concordar com Rex M. O objetivo do padrão de provedor é fornecer apoio para personalização através de uma interface abstrata, onde, como o objetivo de repositório padrão é fornecer um suporte para abstrair os detalhes de undelying banco de dados.