Should my business object relationships go in both directions? The reason I am unsure is that it seems like it ends up being inefficient at times...

Say I have a Report class, which has a ReportLine collection as one of it's properties. Should ReportLine have a property Report? When I load the ReportLine Collection from Report, I could pass in the Report into the ReportLine constructor and each ReportLine would then be linked to the one Report object in memory.

However if I were to create a ReportLine Collection elsewhere, and then I need to check which Report each line is a member of, I would end up creating one Report object per line in memory, which is what seems inefficient to me...

If anyone has any thoughts on this I'd appreciate the feedback...

If you create a report line collection won't those report lines be from the same report? Then the instance of the report should still be shared across all lines in the same way as it would be if the collection is instanced within a report class itself.

-Peter

Peter,

Thanks for that thought.

I failed to mention that sometimes a report lines collection has report lines that always relate to the same report, and sometimes they do not.

I mean, the issue is not one of scalability in my case, but rather of elegant, sensible design. If I call a report line collection on it's own, and I need to iterate through it, and identify what report each line belongs to (each one belonging to a different report), then a report object will be lazy loaded by the Report property of ReportLine one at a time.

I thought about it some more and I think the solution is to create new methods on another object that gets collections that are organized by group differently.

Thanks for your response, I really appreciate it.