Modelo de dominio: relaciones de identificador frente a objetos jerárquicos

Question

Al desarrollar un modelo de dominio hipotético, me he preguntado si el mejor enfoque para relacionar objetos de dominio sería tener un objeto de dominio principal que contenga un puntero (el identificador del niño) o si sería un mejor enfoque usar los objetos secundarios para construir un compuesto dentro del objeto primario.

Puedo ver los pros y los contras de cada enfoque, principalmente una compensación de tamaño versus complejidad, que es a lo que se reduce. Tendería a inclinarme más hacia un enfoque de relación de identificador, ya que no anticipo la necesidad de realizar ningún tipo de carga diferida.

Aunque no están directamente relacionados, los objetos de dominio son POCO simples (equivalente .NET de POJO). Están marcados explícitamente como serializables, ya que hay una buena posibilidad de que eventualmente se crucen entre dominios de aplicación. LINQ hace que el enfoque del identificador relacional sea viable, en mi opinión, y no lo consideraría en absoluto si LINQ no estuviera disponible.

Cualquier idea sería apreciada!

Editar: un par de pensamientos más que podrían hacerme inclinarme hacia un enfoque de solo identificador. Primero sería que la política de almacenamiento en caché de los objetos. Es completamente posible que un objeto primario y secundario tenga TTL diferentes, según lo definido por sus políticas. El segundo sería que la retención de referencia podría limitar la reutilización de objetos, ya que el mismo hijo podría estar en manos de varios padres, en el caso de datos reutilizables. Ambos también se relacionan con el tamaño general de los objetos serializados, también.

Answer 1

Utilizo ambos en mis POCO. Los genero con una lista de hijos en la clase principal y una instancia principal en la clase secundaria.