DDD repositorios como singletons?

Question

Pregunta rápida: ¿Sería una buena o mala idea implementar mis repositorios de estilo de diseño impulsados ??por dominio como singletons? ¿Por qué?

¿O debería usar un contenedor de inyector de dependencia para administrar mis repositorios y decidir si son únicos o no?

Todavía estoy leyendo DDD Quickly , y me gustaría ver algunos buenos ejemplos de repositorio.

Answer 1

He visto un par de formas de hacer esto.

La forma más común es usar la inyección de dependencia para inyectar los repositorios en los objetos que los usan. Por lo general, estas son clases de presentador o controlador, pero en algunos casos el modelo llama al repositorio. Por lo general, es mejor si evitas esto. Si puedes usar un contenedor para hacer esto, entonces hazlo.

También puede hacer que los repositorios implementen el patrón singleton. Trataría de evitar esto porque los singletons generalmente usan métodos estáticos. Esto puede dificultar la prueba del código que llama a los singletons. Si tiene que hacer las cosas de esta manera, asegúrese de separar el código que llama al singleton y use "manual". inyección de dependencia para inyectar los singletons en las clases que los llaman. Esto elimina algunos de los estrechos acoplamientos que de otro modo obtendrías.

He visto algunos ejemplos en los que nunca se llama a los repositorios. Cuando alguien navega por el gráfico de objetos en el modelo y solicita un objeto que no está cargado, el modelo solo genera un evento y el repositorio reacciona a este evento. De esta forma no hay llamadas al repositorio y está completamente desacoplado del modelo. No he usado esta arquitectura yo mismo, pero parece muy limpia.

Answer 2

Use su contenedor de inyección de dependencia para decidir cómo y dónde se crean los repositorios.

Al usar

UserRepository.Instance.Find(userId);

estás creando una barrera para las pruebas.

Si sus repositorios se pasan a los servicios mediante la inyección de constructor, también puede reemplazarlos fácilmente con simulacros.

Answer 3

No estoy seguro de esto y tengo el mismo problema. Creo que debe hacer que un repositorio sea un singleton cuando los objetos con los que trabaja se usan con frecuencia. Y que no debería convertirse en un singleton si usa objetos con los que funciona raramente, porque el repositorio tomaría mucha memoria para los objetos y tal vez se llamaría solo una vez y nunca más durante el uso de la aplicación. Como dije, esto puede no ser un pensamiento correcto.

Answer 4

Digamos que tengo un proyecto realmente enorme, y quiero agregar un nuevo servicio, digamos que sería un representante de hardware en mi sistema. Quiero que este servicio sea accesible a través de muchas clases, quiero asegurarme de que solo haya una instancia de servicio o capa que controle el acceso al servicio. Inyectar este servicio a través de todo mi sistema (más de 200 clases) sería mucho trabajo. Para mí '' Singleton '' o algún " Localizador de servicios " se adapta bien para esta tarea.

Answer 5

Hasta donde entiendo, el dominio contiene solo interfaces de repositorio, lo que significa que puede haber muchas implementaciones de repositorio para una sola interfaz. Por lo tanto, un repositorio ciertamente no puede ser una clase estática, ya que no puede definir métodos estáticos en una interfaz. (Nota: en algunos idiomas puede definir métodos estáticos en una interfaz, pero no tiene mucho sentido para mí).

Los repositorios generalmente se tratan de sincronizar las entidades con bases de datos, archivos, etc. por lo que tienen dependencias no estables. Lo que significa que no pueden ser singletons solo pueden tener dependencias ambientales. Aquí hay un artículo al respecto. La parte divertida, incluso los autores, te dicen que puedes usar singletons en tu dominio.

Según tengo entendido, es mucho más limpio hacer un repositorio que se asegure de tener solo una entidad en lugar de muchas. Esa es la responsabilidad del repositorio, no la entidad si desea que su código cumpla con el principio de responsabilidad única .