How to store one-to-many graph? Passing root or passing root and children seperately?

Question

Suppose in the application, there is a type Teacher and a type Students. A Teacher may have a list of Students. So in design, class Teacher has a field of type Collection of Students (aka List).

Suppose I want to register (insert) a new Teacher with his all new Students.

I either could make a Teacher object and set its StudentList field. In other words, an object graph is to be formed then the root is passed to Data Access Layer to store.

OR

I could make a Teacher object, then make a list of Students and then pass both of them to Data Access Layer to store.

I almost always face this dilemma. I'm aware that it depends on whether the DAL is able to detect changes in a graph or not. But lets assume we are in perfect world of Persistence Ignorant DALs.

Which one is better?

Answer 1

If I were to choose among the two, I would certainly opt for the first solution. I see absolutely no merit in passing a Teacher object with an empty list of Students along with a separately populated free-standing list of Students, as opposed to passing a Teacher object with its own list of students already populated.

However, if it was up to me, I would not choose either of these two approaches.

Keep in mind that the fact that the teacher has a list of students is an elaborately constructed and maintained illusion that your persistence layer provides you with. From a relationally normalized point of view, the teacher does not actually have a list of student; instead, either each student has a teacher, or, if a student may need to have many teachers, then this is realized by means of a many-to-many relationship.

The many-to-many relationship is implemented as an extra table containing rows with pairs of just teacher ids and student ids. In this case, the illusion of a collection applies to students, too: a student may have a list of teachers just as easily as a teacher may have a list of students. So, when you create a student, why not create them with their list of teachers already filled in? Clearly, this is absurd, so I think that the whole idea of creating entities with pre-filled-in relationships is absurd.

So, what I would do is that I would instantiate and pass around separate teacher entities and student entities, (without any pre-filled-in relationships among them,) and then in separate steps I would specify the relationships among them on an individual basis.

Answer 2

Neither is better. It depends on the intended atomicity of the change, and how that matches with the client interaction.

If you're manipulating things through a UI and a user first creates a teacher, and then creates or links to 1 or more students, doing them separately and sequentially is correct.

If you're processing a service request which batches in classes, you want to do them in a single atomic action, and that's more naturally expressed by passing the whole graph.

Ideally, your DAL should handle both use cases, as the functional events here are different and have different constraints.