Detección de cambios en entidades dentro de una raíz agregada

Question

Estoy buscando ver qué enfoques podrían haber tomado las personas para detectar cambios en las entidades que forman parte de sus agregados. Tengo algo que funciona, pero no estoy loco por eso. Básicamente, mi repositorio es responsable de determinar si el estado de una raíz agregada ha cambiado. Supongamos que tengo una raíz agregada llamada Book y una entidad llamada Page dentro del agregado. Un Libro contiene una o más entidades Page , almacenadas en una colección Pages .

Principalmente, los escenarios de inserción frente a actualización se realizan inspeccionando la raíz agregada y sus entidades para determinar la presencia de una clave. Si la clave está presente, se presume que el objeto ha sido guardado en el origen de datos subyacente. Esto lo convierte en candidato para una actualización; pero no es definitivo basado solo en eso para las entidades. Con la raíz agregada, la respuesta es obvia, ya que solo hay una y es el punto de entrada singular, se puede suponer que la presencia clave dictará la operación. Es un escenario aceptable, en mi caso, guardar de nuevo la raíz agregada para poder capturar una fecha de modificación.

Para ayudar a facilitar este comportamiento para las propias entidades, mi clase EntityBase contiene dos propiedades simples: IsUpdated () , IsDeleted () . Ambos valores predeterminados a falso. No necesito saber si es nuevo o no, porque puedo hacer esa determinación basada en la presencia de la clave, como se mencionó anteriormente. Los métodos en la implementación, en este caso la Página, tendrían cada método que cambie el conjunto de datos de respaldo IsUpdated () a verdadero.

Entonces, por ejemplo, Page tiene un método llamado UpdateSectionName () que cambia el valor de respaldo de la propiedad SectionName , que es de solo lectura. Este enfoque se usa de manera consistente, ya que permite un punto de conexión lógico de validadores en el método (evitando que la entidad entre en un estado no válido) que realiza esa configuración de datos. El resultado final es que tengo que poner un this.IsUpdated () = true; al final del método.

Cuando la raíz agregada se envía al repositorio para Save () (un cambio lógico a Insert () o Update () operación), puede iterar sobre la colección Pages en el Book , buscando cualquier página que tenga uno de tres escenarios:

1. Sin clave. Se insertará una Página sin clave.
2. IsDeleted = true; Una eliminación prevalece sobre una actualización, y la eliminación se confirmará, ignorando cualquier actualización para la Página .
3. IsUpdated = true; Se confirmará una actualización para la página.

Hacerlo de esta manera me impide actualizar a ciegas todo lo que está en la colección de Páginas, lo que podría ser desalentador si hubiera varios cientos de entidades de Página en el Libro, por ejemplo. Había estado considerando recuperar una copia del Libro, y hacer una comparación y solo confirmar los cambios detectados (inserciones, actualizaciones y eliminaciones en función de la presencia y / o comparación), pero parecía ser una manera tremendamente habladora de hacerlo. .

El principal inconveniente es que el desarrollador debe recordar establecer IsUpdated en cada método de la entidad. Olvide uno, y no podrá detectar cambios para ese valor. He jugado con la idea de algún tipo de almacén de respaldo personalizado que pueda marcar los cambios de manera transparente, lo que a su vez podría hacer que IsUpdated sea una propiedad de solo lectura que el repositorio podría usar para agregar actualizaciones.

El repositorio está utilizando una implementación de patrón de unidad de trabajo que basa sus acciones en la marca de tiempo generada cuando se le agregó la raíz agregada. Dado que puede haber múltiples entidades queu

Answer 1

En resumen, mi respuesta es que fui con lo que propuse. Está funcionando, aunque estoy seguro de que hay margen de mejora. Los cambios en realidad tomaron muy poco tiempo, así que siento que no navegué demasiado lejos de los directores de KISS o YAGNI en este caso. :-)

Todavía siento que hay espacio para los problemas relacionados con el tiempo en las operaciones, pero debería poder solucionarlos en las implementaciones del repositorio. No es la solución ideal, pero no estoy seguro de que valga la pena reinventar la rueda para corregir un problema que se puede evitar en menos tiempo del que lleva solucionarlo.