¿Estamos utilizando el patrón de repositorio correcto?

Estamos usando un montón de clases separadas con el sufijo -repositorypara recuperar los datos de la base de datos; para cada tabla su propio repositorio.

Tenemos, por ejemplo, una customerrepositoryclase que tiene todo tipo de métodos para recuperar clientes, y una vacancyrepositoryque tiene todo tipo de métodos para recuperar vacantes.

Tengo dos preguntas sobre esta forma de hacer las cosas:

¿Qué tal obtener datos que abarquen varias tablas? Por ejemplo, tengo una pantalla que muestra a todos los clientes que aún no han creado una vacante. ¿Puede un customerrepositorymétodo de uso de los vacancyrespositorydos repositorios devolver resultados y hay una clase más alta en la jerarquía (nombremos a dataservice) que obtiene los resultados de ambos repositorios y los combina en 1 resultado?
¿Cuánta lógica puede manejar ese repositorio?
Creo que está bien implementar 'where active == true' en un repositorio para recuperar solo registros activos, o incluso esa lógica simple debería ser manejada por una clase más alta en la jerarquía (nombremos a dataservice)?

El ejemplo con el que me encontraba ahora es este:

Tenemos una lista de preguntas, que contiene una o más preguntas.
La pregunta puede tener un resultado, que se mantiene en una tabla separada.
Entonces, cuando desee recuperar el resultado total de la lista de preguntas, debe combinar los datos de la questionlisttabla, la tabla de preguntas y la questionstatustabla.

En este momento tenemos 3 repositorios diferentes para estas tablas.

Si quisiera preguntar questionlistrepositorycuál es el resultado total para la lista número 12, tendría que obtener datos de otros dos repositorios y, por lo tanto, tener algo de lógica, ¿está permitido?

¿O hay questionlistdataservicealguien que sepa qué repositorios usar?

Una cosa más: nuestros repositorios pueden generar un servicio IQueryablepara que un servicio de llamadas pueda combinar fácilmente los resultados, pero ¿qué tal si este no es el caso? No creo que sea una buena idea recuperar todo el contenido de las tres tablas del base de datos.

c# design design-patterns repository

— Michel
fuente

Por lo general, en los accesos a múltiples tablas, la tabla dominante está determinada por la tabla del registro que debe existir antes de que la consulta la recupere. En LEFT OUTER JOIN, esa sería la primera tabla mencionada y en RIGHT OUTER JOIN, sería la segunda.

— Neil

El repositorio devuelve objetos de dominio y está construido sobre capas de mapeo. Para un dominio muy simple, los objetos de dominio y las tablas de la base de datos pueden ser muy parecidos.

Si su repositorio siempre devuelve una representación exacta de su estructura de datos, entonces podría ser Table Data Gateway, también conocido como Data Access Object (DAO).

Ejemplo: su base de datos tiene tablas para persona y dirección. En su aplicación, la dirección del dominio no es una entidad propia, es solo una propiedad de la Persona. En este caso, no tendría PersonRepository y AddressRepository. Solo tienes PersonRepository. El dominio no debe preocuparse por la persistencia de los datos del dominio. Esas responsabilidades están en una capa detrás del repositorio.

Según su ejemplo, parece que en realidad tiene DAO y acaba de nombrarlos repositorios.

— simoraman
fuente

Entonces, al crear un repositorio, también puedo tener una puerta de enlace de datos de Table un nivel más profundo, y nuestros repositorios son en realidad TDG.

— Michel

Podría, pero sopesar el costo y los beneficios. No se deje intimidar por mantener separados los DAO y los repositorios por el principio de "capas" de código. Haz lo que sea más legible en este caso. La separación, y la capa de abstracción resultante, pueden ser útiles si sus repositorios tienden a hacer una gran cantidad de recombinación de los datos en los DAO.

— Mihai Danila