¿Es el patrón de repositorio el mismo que el modelo de proveedor Asp.net?

Question

Desde Asp.net 2.0, existe el Modelo de Proveedor. En el detalle de la implementación, un proveedor es una clase derivada de ProviderBase que es una clase abstracta en lugar de una interfaz, pero de todos modos el Modelo de Proveedor está ahí para que podamos tener una implementación diferente para intercambiar la salida simplemente editando el web.config. Por ejemplo, si crea una aplicación de blog, puede tener un BlogProvider: ProviderBase, luego puede tener implementaciones de BlogProvider como: SqlBlogProvider, OracleBlogProvider e incluso MockBlogProvider para probar.

Ahora, el Repository Pattern se está volviendo popular, y creo que es para satisfacer la misma necesidad, aunque en los detalles de implementación, normalmente usa interfaces, por lo que IBlogProvider, e inyectaría implementaciones diferentes mediante constructores en lugar de propiedades, pero esencialmente no veo la diferencia en lo que estos 2 patrones nos dieron.

Personalmente, creo que el modelo de proveedor es más natural para mí en la implementación. Entonces, ¿hay alguna diferencia entre ellos o son exactamente lo mismo con diferentes nombres dados por diferentes comunidades?

Agradecería cualquier comentario sobre esto, Gracias, Ray.

Answer 1

Los patrones del Repositorio y del Proveedor se superponen, pero no describen formalmente la misma cosa. Casi diría que el Repositorio es un subconjunto del Proveedor. En la práctica, creo que el patrón Repository fue a partir de una necesidad específica - repositorios de abstracción - y evolucionó en la comunidad en un patrón de abstracción más genérico. En ese sentido, han llegado a ser términos diferentes que describen el mismo concepto. Sin embargo, a partir de las definiciones originales, son diferentes en su alcance:

• El propósito del patrón Repositorio es abstraer los detalles de un repositorio de los datos de distancia desde la aplicación.

• El propósito del modelo de proveedor es abstraer los detalles de cualquier cosa lejos de la aplicación. Puede tratarse de un repositorio de datos, pero con la misma frecuencia es un tipo de lógica.

Por ejemplo, en nuestra aplicación tenemos un ContextFactoryProvider, que contiene diferentes tipos de lógica para determinar qué ContextFactory de usar. No hay repositorio de datos en este caso; es puramente lógica de aplicación que necesita cambiar arbitrariamente; el modelo de Proveedor nos permite usar el Single Responsibility Principle para aislar cada clase de lógica en su propia clase y cambiar esa lógica fácilmente.

Answer 2

No puedo estar de acuerdo con Rex M. El propósito del patrón de proveedor es proporcionar soporte para personalización a través de una interfaz abstracta, donde el propósito del patrón de repositorio es proporcionar un soporte para abstraer los detalles de la base de datos undelying.