¿Debería un repositorio llamar a otro repositorio? ¿O debería un repositorio llamar a una capa de servicio?

Question

Estoy intentando descubrir cómo abordar este problema. Tengo que insertar algunos datos en las tablas 2 a cuadros A y B. Deja llamada

Table A has these columns 
AId<PK> 
A1 
A2 
A3 

Table B has 
AId<PK> 
A1 
B2 
B3 
B4 

Ahora mi primera pregunta fue otro repositorio debe llamar a otro repositorio? No creo que esto resuelva mi problema actual, pero solo quiero saber esto para futuras referencias.

Ahora en mi problema.

cuando llamo a create en mi capa de repositorio (TableARepository) para Crear la Tabla A. Creo también los campos para tableB también.

// linq to sql. 
    TableA myATable = new TableA(); 
    dbContext.myATable.A1 = "hi"; // all these values would come from parameters. 
    dbContext.myATable.A2 = "bye"; 
    dbContext.myATable.A3 = "go"; 

    dbContext.myATable.insertOnSubmit(TableA); 
    dbContext.SubmitChanges(); 

    TableB myBTable = new TableB(); 
    dbContext.myBTable.AId = myATable.AId; 
    dbContext.myBTable.A1 = myATable.A1; 
    dbContext.myBTable.B2 = "2"; 
    dbContext.myBTable.B3 = "3"; 
    dbContext.myBTable.B4 = "4"; 

    dbContext.myATable.insertOnSubmit(TableB); 
    dbContext.SubmitChanges(); 

así que creo que está muy bien y no creo que tendría que llamar repositorio myBTable (para crear TableB) para éste y una capa de servicio.

Ahora aquí está el problema. La tabla TableB solo debe tener la información insertada en esta tabla si y solo si no es igual a "hola".

so param1 != "hi" // insert 
    param1 == "hi" // ignore and only insert table A 

por lo que esto significaría que tendría que envolver mi TableB como esto

if(param1 != "hi") 
{ 
    TableB myBTable = new TableB(); 
    dbContext.myBTable.AId = myATable.AId; 
    dbContext.myBTable.A1 = myATable.A1; 
    dbContext.myBTable.B2 = "2"; 
    dbContext.myBTable.B3 = "3"; 
    dbContext.myBTable.B4 = "4"; 

    dbContext.myATable.insertOnSubmit(TableB); 
    dbContext.SubmitChanges(); 
} 

Ahora no estoy seguro de si debería estar haciendo esto aquí, ya que esto parece casi como la lógica de negocio. sin embargo, al mismo tiempo, no estoy seguro de cómo hacer esta lógica comercial, ya que de todas formas, aún tengo que pasar el valor para insertar en el método create, incluso si es nulo (A1 es un campo que puede ser anulado).

Así que debería llamar al paso de capa de servicio tableB en el TableA.Id, A1 y verificar qué es A1. Si es bueno, vaya al repositorio de TableB e insértelo de esa forma.

Por lo tanto TableARepostiory -> TableB service layer -> TableBRepository (si se encuentra que ese valor! = "Hola").

Así que no estoy seguro de qué hacer.

Answer 1

No, no puedo pensar en una razón para que un repositorio llame a otro repositorio, ni a otro servicio. Su única preocupación debería ser persistir en sus entidades y recuperar entidades de un almacén de datos. Deberían ignorar la mayoría de los aspectos de su aplicación, excepto el dominio subyacente.

Parece que está asumiendo que debería ser un repositorio por tabla, lo cual es incorrecto. Debería haber un repositorio por raíz agregada, y ese repositorio debería encargarse de almacenar los datos en todas las tablas subyacentes relacionadas. Está bien que el repositorio tenga cierta lógica relacionada con dónde o cómo guardar los datos, pero sería mejor que se encapsule en un área común cuando sea posible.

Por ejemplo, si tuviera objetos personales y tuviera que guardarlos en diferentes tablas según su sexo, podría hacerlo utilizando la herencia (si (la persona es Mujer) guardar aquí ...) o las propiedades del objeto (si (person.Gender == Gender.Female) save here ...) o Specifications (if (FemaleSpecification.IsSatisfiedBy (person)) guardar aquí ...).

Answer 2

La cláusula guard (param1! = "Hi") debe estar en una capa superior, como una capa de servicio de aplicación.

La capa de servicio debe coordinar los dos repositorios.