¿Cómo se deben manejar las entidades padre e hijo en el patrón de repositorio?

Question

Estoy trabajando en la creación de un sitio de imágenes y me pregunto cómo debería estructurar los métodos Crear/Actualizar en mi repositorio Linq a Sql?

que tienen una entidad de fotos que está estructurado como:

public class Image 
{ 
    public int ID { get; set; } 
    public int OwnerId { get; set; } 
    public string Url { get; set; } 
    public IEnumerable<Tag> Tags { get; set; } 
} 

Tengo las siguientes tablas: Imágenes, Etiquetas, ImageTag

Ahora, me pregunto cuando llamo mi método CreateImage en mi ImageRepository, ¿debería también crear las etiquetas en la tabla Etiquetas y hacer las asignaciones en la tabla ImageTag?

Del mismo modo, cuando llamo a UpdateImage, debería verificar si las etiquetas han cambiado, y si tienen eliminar entradas en la tabla ImageTag y agregar otras (además de agregar nuevas etiquetas a la tabla de etiquetas) ?

¿O deberían ocurrir estos dos casos de uso en una llamada al repositorio por separado?

Básicamente, ¿cómo se maneja esta relación padre-hijo, uno a muchos, típicamente en un repositorio linq a sql típico?

Answer 1

Yo diría que no es responsabilidad del repositorio entender las relaciones entre las entidades en su modelo. Después de todo, si cambiara la forma en que persistiera en sus datos (por ejemplo, en una solución sin sql, o incluso si solo cambiara su esquema db), sus entidades y su modelo no deberían cambiar.

Por lo tanto, su mejor opción es tener llamadas de repositorio separadas y envolver las llamadas dentro de una unidad de trabajo. (A Unit of Work es básicamente una transacción abstraída).

Su unidad de trabajo y las diversas llamadas al repositorio serían una capa de abstracción sobre el repositorio. No conozco el resto de tu modelo, así que podrían ser cosas diferentes. Podría ser un método en el objeto Imagen. Podría tener un Mediator. O bien, si se aproxima a esto desde una perspectiva DDD, un Servicio de dominio.

Saludos.