Le modèle de référentiel est-il identique au modèle de fournisseur Asp.net?

Question

Depuis Asp.net 2.0, il existe un modèle de fournisseur. Sur le détail de l'implémentation, un fournisseur est une classe dérivée de ProviderBase, qui est une classe abstraite plutôt qu'une interface, mais le modèle de fournisseur y est de toute façon, de sorte que nous pouvons avoir une implémentation différente à échanger en sortant simplement en modifiant le fichier web.config. Par exemple, si vous créez une application de blog, vous pouvez avoir un BlogProvider: ProviderBase, puis vous pouvez avoir des implémentations de BlogProvider telles que: SqlBlogProvider, OracleBlogProvider et même MockBlogProvider pour les tests.

Maintenant, Repository Pattern est en train de devenir populaire, et j’ai le sentiment que c’est pour satisfaire le même besoin, même si dans le détail de l’implémentation, vous utilisez normalement des interfaces, donc IBlogProvider, et vous injecteriez différentes implémentations via des constructeurs plutôt que des propriétés, mais Essentiellement, je ne vois pas la différence entre ce que ces 2 modèles nous ont donné.

Personnellement, je pense que Provider Model est plus naturel pour moi lors de la mise en œuvre. Alors, y a-t-il une différence entre eux ou s'agit-il exactement de la même chose avec des noms différents donnés par des communautés différentes?

J'apprécierais vos commentaires à ce sujet, Merci, Ray.

Answer 1

Les modèles de référentiel et de fournisseur se chevauchent, mais ils ne décrivent pas formellement la même chose. Je dirais presque que le référentiel est un sous-ensemble de fournisseur. En pratique, je pense que le modèle de référentiel était né d'un besoin spécifique - l'abstraction de référentiels - et a évolué au sein de la communauté en un modèle d'abstraction plus générique. À cet égard, ils sont devenus des termes différents qui décrivent le même concept. Cependant, à partir des définitions d'origine, leur portée est différente:

• Le modèle de référentiel a pour objet d'extraire les spécificités d'un référentiel de données, loin de l'application.

• Le modèle de fournisseur a pour but d’abstraire les spécificités de tout de l’application. Cela peut être un référentiel de données, mais c'est tout aussi souvent une sorte de logique.

Par exemple, dans notre application, nous avons un ContextFactoryProvider, qui contient différents types de logique pour déterminer quel ContextFactory doit être utilisé. Il n'y a pas de référentiel de données dans ce cas; c'est une logique d'application qui doit changer arbitrairement; le modèle de fournisseur nous permet d'utiliser le principe de responsabilité unique pour isoler chaque type de logique dans sa propre classe et permutez cette logique facilement.

Answer 2

Je ne suis pas d'accord avec Rex M. Le but du modèle fournisseur est de fournir un support pour la personnalisation via une interface abstraite, alors que l'objectif du modèle de référentiel est de fournir un support pour résumer les détails de la base de données en perte de vitesse.