While fleshing out a hypothetical domain model, I have found myself wondering whether the better approach in relating domain objects would be to have a parent domain object contain a pointer (the identifier of the child) or if it would be a better approach to use the child objects to build a composite within the parent object.
I can see the pros and cons of each approach, mostly a trade off of size versus complexity, being what it boils down to. I would tend to lean more towards a identifier relationship approach, as I am not anticipating the need for doing any sort of lazy loading.
Although not directly related, the domain objects are simple POCOs (.NET-equivalent of POJOs). They are explicitly marked as serializable, as there is a good chance that they will eventually cross between application domains. LINQ makes the relational identifier approach viable, in my opinion, and I would not consider it at all if LINQ were not available.
Any thoughts would be appreciated!
Edit: A couple of more thoughts that might have me lean towards an identifier-only approach. First would be that the caching policy of the objects. It is entirely possible that a parent and child object have different TTLs, as defined by their policies. The second would be that the reference holding might limit object reuse, in that the same child might be held by multiple parents – in the case of reusable data. Both of these also relate to the overall size of the serialized objects, as well.
I use both on my POCOs. I generate them with a list of children on the parent class and one parent instance on the child class.