asp.net - Should A repository call another repository? Or should a repository call a service layer?

Question

I am trying to figure out how to tackle this problem. I have to insert some data into 2 tables lets call them Table A and Table B.

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

Table B has
AId<PK>
A1
B2
B3
B4

Now my first question was should another repository call another repository? I don't think this will solve my current problem but I just want to know this for future reference?

Now onto my problem.

when I call a create in my repository layer(TableARepository) to Create Table A. I create right away the fields for tableB too.

// 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();

So I think this is fine and I don't think I would need to call myBTable repository(to create tableB) for this or a service layer.

Now here is the problem. TableB table should only have the information inserted into this table if and only if it is not equal to "hi".

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

so this would mean I would have to wrap my TableB like this

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();
}

Now I am not sure if I should be doing this here since this seems almost like business logic. yet at the same time I am not sure how to do this business logic since either way I still have to pass in the value to insert into the create method even if it is null(A1 is a nullable field).

So should I call the tableB service layer pass in the TableA.Id, A1 and check what A1 is. If good then go to the TableB repository and insert it that way?

So TableARepostiory -> TableB service layer -> TableBRepository(if found that that value != "hi").

So I am not sure what to do.

Answer 1

No - i cannot think of a reason for a repository to call another repository, nor another service. Their only concern should be persisting your entities and retrieving entities from a datastore. They should be ignorant to most aspects of your application except for the underlying domain.

It sounds like you are assuming their should be a repository per table, which is incorrect. There should be a repository per aggregate root, and that repository should take care of storing data to all of the underlying, related tables. It is OK for the repository to have some logic pertaining to where or how to save the data, but it would be best for that to be encapsulated in a common area when possible.

For example if you were to have person objects and needed to save to different tables according to gender, you could do this using inheritance ( if (person is Woman) save here... ) or properties on the object ( if (person.Gender == Gender.Female) save here... ) or Specifications ( if (FemaleSpecification.IsSatisfiedBy(person)) save here... ).