Después de ver el vídeo por Greg Yound en DDD¿Cómo implementar CQS con cambios en la memoria?
http://www.infoq.com/interviews/greg-young-ddd
me preguntaba cómo se puede poner en práctica la separación de comandos de consulta (SCC) con DDD cuando se tiene en cambios en la memoria?
Con CQS que tiene dos repositorios, uno de los comandos, uno para consultas. Además de dos grupos de objetos, objetos de comando y objetos de consulta. Los objetos de comando solo tienen métodos y no tienen propiedades que puedan exponer la forma de los objetos, y no se deben usar para mostrar datos en la pantalla. Los objetos de consulta, por otro lado, se usan para mostrar datos en la pantalla.
En el video los comandos van siempre a la base de datos, y de esta manera puede utilizar el repositorio de consulta para recuperar los datos actualizados y volver a mostrar en la pantalla.
¿Podría usar CQS con algo así como editar pantalla en ASP.NET, donde se realizan cambios en la memoria y la pantalla debe actualizarse varias veces con los cambios antes de que los cambios se mantengan en la base de datos?
Por ejemplo
- voy a buscar un objeto de consulta desde el repositorio de consulta y mostrarlo en la pantalla
- que haga clic en Editar
- que vuelva a recuperar un objeto de consulta desde el repositorio de objetos de consulta y mostrarlo en la la forma en modo de edición
- que cambiar un valor en el formulario, que autoposts atrás y va a buscar el objeto de comando y emite el comando relevante
- Qué hacer: ahora necesito para mostrar la UPDA objeto ted a medida que el comando realizó cambios en los campos calculados. Como el objeto de comando no se ha guardado en la base de datos, no puedo usar el repositorio de consultas. Y con CQS no estoy destinado a exponer la forma del objeto de comando para mostrar en la pantalla. ¿Cómo recuperaría un objeto de consulta con los cambios actualizados para mostrar en la pantalla?
Un par de soluciones posibles que puedo pensar es tener un repositorio de sesión, o una forma de obtener un objeto de consulta desde el objeto de comando. ¿O no se aplica CQS a este tipo de escenario?
Me parece que en el video los cambios persisten directamente en la base de datos, y no he encontrado un ejemplo de DDD con CQS que resuelva el problema de los cambios de lotes en un objeto de dominio y actualice la vista del objeto de dominio modificado antes de emitir finalmente un comando para guardar el objeto de dominio.
Gracias por la respuesta. Me pregunto qué tan común/bueno es un diseño para usar CQS cuando los cambios están en la memoria, en lugar de persistir directamente a la base de datos? Esto es básicamente lo que hemos propuesto es usar repositorios de sesión para permitir que el repositorio de consultas acceda a los datos del comando a través de una variable de sesión. Quizás necesite repositorios HttpContext más tarde. ¿Alguien ha visto esto implementado antes? Pensamientos apreciados. – Ian
En mi opinión, el método que utiliza para manipular una fuente de datos no debe depender del tipo de fuente de datos. El patrón Repositorio le permite abstraer estas diferencias, lo que le permite tratar cualquier fuente de datos como si se tratara de una colección de objetos consultable.Depende de las implementaciones de repositorio individuales determinar la fuente de datos objetivo, por lo que en teoría tendrías un 'InMemoryRepository' y un 'DatabaseRepository', o lo que sea. –
Sí, entiendo que puede cambiar el repositorio de InMemory para el repositorio de la base de datos. Parte del valor de CQS es que usted emita comandos a la base de datos y retire por separado los datos actualizados con el repositorio de consultas. En memoria, el objeto de comando está en sesión, por lo que el repositorio de consultas solo puede recuperar datos en el objeto de comando. Con la versión de la base de datos, entonces el objeto de consulta puede ser totalmente diferente al objeto de comando, simplemente parece que con la memoria CQS la relación es mucho más cercana. Preguntándose cómo encaja esto con lo que CQS estaba tratando de lograr – Ian