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é?repositorios DDD como singletons?
¿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 rápidamente, y me gustaría ver algunos buenos ejemplos de repositorio.
He visto un par de formas de hacerlo.
La forma más común es usar la inyección de dependencia para inyectar los repositorios en los objetos que los utilizan. Por lo general, estas son clases de presentador o controlador, pero en algunos casos el modelo llama al repositorio. Usualmente es mejor si evitas esto. Si puedes usar un di-contenedor para hacer esto, entonces ve por él.
También puede hacer que los repositorios implementen el patrón singleton. Intentaré evitar esto porque los singleton usualmente usan métodos estáticos. Esto puede hacer que sea más difícil probar el 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 usar la inyección de dependencia "manual" para inyectar los singletons en las clases que los llaman. Esto elimina parte del acoplamiento estrecho que de otro modo obtendrías.
He visto algunos ejemplos en los que nunca se llama a los repositorios. Cuando alguien navega el gráfico de objetos en el modelo y solicita un objeto que no está cargado, el modelo simplemente 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, pero parece muy limpia.
Utilice su contenedor de inyección de dependencias para decidir cómo y dónde se crean los repositorios.
Mediante el uso de
UserRepository.Instance.Find(userId);
va a crear una barrera a prueba.
Si sus repositorios se pasan a servicios utilizando Constructor Injection, entonces también puede reemplazarlos fácilmente con simulaciones.
No estoy seguro de esto y tengo el mismo problema. Creo que debería hacer un repositorio único cuando los objetos con los que trabaja se usan con frecuencia. Y que no debería ser un singleton si usas objetos con los que funciona rara vez, ya que el repositorio tomaría mucha memoria para objetos y tal vez solo se llamaría una vez y nunca más durante el uso de la aplicación. Como dije, esto puede no ser correcto.
Con un repositorio no único, aún podría ser posible compartir el estado interno con otras instancias de ese mismo repositorio mediante el uso de un estado interno estático o mediante un patrón de estado compartido como el patrón NWorkspace. – jpierson
Digamos que tengo un proyecto realmente grande, y quiero agregar un nuevo servicio digamos que sería un representante de hardware en mi sistema. Deseo 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 a esta tarea.
Por lo que yo entiendo, el dominio contiene solo una interfaz de repositorio, lo que significa que puede haber muchas implementaciones de repositorio para una única interfaz. Entonces, 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 suelen ser para sincronizar las entidades con bases de datos, archivos, etc., por lo que tienen dependencias no estables. Lo que significa que no pueden ser singletons pueden tener solo dependencias ambientales. Aquí hay un article al respecto. La parte graciosa incluso los autores te dicen que puedes usar singletons en tu dominio.
Según entiendo, es mucho más limpio crear un repositorio que asegure que solo tiene una única entidad en lugar de muchas. Esa es la responsabilidad del repositorio, no de la entidad si desea que su código cumpla con el single responsibility principle.
Creo que el concepto de carga diferida a través de eventos que usted mencionó es interesante, ¿podría indicarme algún material o ejemplo del que pueda estar consciente que pueda estar utilizando esa estrategia? Me gustaría evaluarlo para mi propio uso. – jpierson
@jpierson Busqué pero no encontré ningún ejemplo. Recuerdo que alguien hizo una demostración del enfoque del evento en una charla sobre DDD, pero para ser honesto, todo fue bastante teórico. – Mendelt