comparar repositorio vs proveedor vs servicio

Question

Necesito implementar una lógica que será recuperar datos desde algún origen de datos remoto. Y ahora tengo que decidir qué concepto debería necesitar: Proveedor, Repositorio o Servicio.

En realidad no entiendo muy bien toda la gran diferencia entre eso. Sí, sé que el repositorio es algo más específico de los datos y no debe contener ninguna lógica comercial. El proveedor por otra parte puede contener algunas reglas comerciales además de administrar datos. Y el Servicio también podría contener cierta lógica comercial además de administrar los datos. Entonces, ¿cuál es la diferencia entre el Servicio y el Proveedor?

Desde el otro punto de vista, creo que usar el servicio es un mejor enfoque para mostrar que es una abstracción para el acceso remoto.

En conclusión: todos estos enfoques parecen razonables y estoy completamente confundido con él. Será muy apreciado si alguien me ayuda con eso.

Answer 1

El repositorio y el servicio no son mutuamente excluyentes. De hecho, a menudo se usan juntos.

La capa de servicio se encuentra en la parte superior de los objetos de su dominio y proporciona una interfaz grafica para las operaciones comerciales. Por lo general, describe los casos de uso de su aplicación. La capa de servicio usa repositorios para obtener sus objetos de dominio y delegarles una mayor ejecución cuando sea posible.

El Repositorio actúa como una colección de objetos de dominio persistentes. Proporciona métodos para encontrar los objetos correctos utilizando algunos criterios. También proporciona métodos para guardar esos objetos.

Las implementaciones del repositorio en la naturaleza varían bastante. Repositorios podrían proporcionar métodos como

List<Person> findPersonByName(String name) 

o un enfoque más genérico con criterios objetos

List<Person> find(Criteria criteria) 

lectura adicional: service layer, repository

No estoy familiarizado con el patrón de Proveedor.

Answer 2

Todos estos enfoques parecen razonables y estoy completamente confundido con .

No es de extrañar que está confundido, ya que la gente parece que recurrir a servicios y proveedores para cualquier cosa y su contrario en estos días;)

El patrón Repositorio se define con mayor precisión sin embargo: es un conjunto de objetos del mismo tipo que puede consultar, agregar o quitar de, apareciendo como una colección en memoria para las personas que llaman pero en realidad asignadas a un almacenamiento persistente detrás de las escenas.

¿Qué hay de encontrar un nombre que realmente represente lo que hace su objeto en lugar de utilizar bolsas de conceptos diluidas y diluidas? Estoy a favor de los patrones y las expresiones idiomáticas compartidas que son inmediatamente reconocibles para todos los desarrolladores, pero no puedo ver el uso de las palabras cuando ya no significan nada preciso ...

Answer 3

En palabras simples, tiene su servicio Service S que usa Repository R para bases de datos CRUD o operaciones de búsqueda. Supongamos que tiene diferentes servicios S1, S2, S3 cada uno tiene los mismos contratos (interfaz) pero diferentes implementaciones, necesita un proveedor que elija cuál usar en qué contexto. Puede sustituir el patrón del proveedor usando la inyección de dependencias para que su código es menos acoplada y dirección no es responsable de los servicios instanciando, su cliente una instancia del servicio adecuado con DI de contenedores

Answer 4

Repositorio encapsula una lógica de datos específica para obtener datos, por ejemplo ICustomerRepository puede tener implementaciones SqlCustomerRepository, MySqlCustomerRepository. Sin embargo, DataProvider abstrae la lógica de datos y utiliza medios configurados para resolver los datos. Los datos pueden provenir de bases de datos, archivos planos o bases de datos NoSql. Además, la configuración de DataProvider se puede cambiar dentro del contexto a diferencia de una implementación de repositorio inyectada en un servicio. Por otro lado, como Nefron explicó que el servicio opera sobre la lógica comercial definida en las entidades.