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

Question

Desde Asp.net 2.0, existe el modelo de proveedor. En el detalle de 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 simplemente editando web.config. Por ejemplo, si crea una aplicación de blog, puede tener un BlogProvider: ProviderBase, entonces puede tener implementaciones de BlogProvider como: SqlBlogProvider, OracleBlogProvider e incluso MockBlogProvider para probar.

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

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 lo mismo con diferentes nombres dados por diferentes comunidades?

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

Answer 1

Los patrones de Repositorio y Proveedor se superponen, pero no describen formalmente lo mismo. Casi diría que el repositorio es un subconjunto de proveedor. En la práctica, creo que el patrón de repositorio surgió de una necesidad específica, abstraer repositorios, y evolucionó en la comunidad hacia un patrón de abstracción más genérico. En ese sentido, se han convertido en términos diferentes que describen el mismo concepto. Sin embargo, a partir de las definiciones originales, tienen un alcance diferente:

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

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

Por ejemplo, en nuestra aplicación tenemos un ContextFactoryProvider, que contiene diferentes tipos de lógica para determinar qué ContextFactory 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 Principio de responsabilidad única para aislar cada tipo de lógica en su propia clase e intercambie esa lógica fácilmente.

Answer 2

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