Devo aggiungere complessità ai miei oggetti dati POCO per riflettere le loro relazioni o avvolgerli in una classe più complessa?

Ho una serie di oggetti POCO immutabili che riflettono il contenuto del database. Questi hanno una relazione uno-molti:

Property ha un PropertyType , che ha molti PropertyTypeMetadata s.

Poiché Property ha solo un PropertyType , e contiene informazioni che saranno spesso utilizzate dai consumatori di Property , ho aggiunto complessità al mio oggetto POCO integrandolo. Property ha un riferimento a PropertyType . Ogni volta che ne ottengo uno dal database faccio un join e costruisco un oggetto con PropertyType present:

class Property
{
    public PropertyType MyPropertyType;
}

Sono un po 'a disagio con questo. Sembra essere "inquinante" la purezza del mio oggetto dati Property aggiungendo le relazioni ad esso.

Tuttavia è molto conveniente, poiché è quasi sempre necessario conoscere PropertyType di una proprietà.

Da quando ho aggiunto PropertyTypeMetadata sto trovando una situazione simile. Faccio spesso due chiamate di accesso ai dati con PropertyTypes, una per ottenere la proprietà, quindi di nuovo per ottenere i suoi metadati. E ancora, ho spesso bisogno di accedere a PropertyTypeMetadata quando sto consumando le Proprietà - è spesso un po 'complicato per ottenere un set di Proprietà basato su una condizione, quindi capire come ottenere tutti i Metadata che si riferiscono a loro.

Come risultato, sto iniziando a considerare di aggiungere PropertyTypeMetadata come una proprietà di PropertyType e di fare la stessa cosa di cui sopra.

Immagino di avere tre opzioni:

1. Mantieni i miei oggetti POCO "puri" e super semplici. Riflettevano le tabelle del database che rappresentano e poco altro. Sarà più "sforzo" e complessità per il consumatore, poiché dovrebbero eseguire molte chiamate diverse per raccogliere i dati correlati in base alle esigenze.
2. Muddy i miei oggetti POCO aggiungendo le relazioni comuni e desiderosi di caricare e popolare queste relazioni. Gli oggetti POCO diventano più complessi, non riflettono le tabelle del database così bene. Ma consumarli è più facile dato che i dati di cui hai bisogno sono a portata di mano. Ciò rende, per esempio, la creazione o l'aggiornamento di un oggetto molto più disordinato.
3. Una specie di ibrido. Forse potrei avere i semplici oggetti POCO e avvolgerli in un tipo più complesso?

interface IProperty {...}
class POCOProperty {...}

interface IPropertyType {...}
class POCOPropertyType {...}

interface IPropertyTypeMetadata {...}
class POCOPropertyTypeMetadata {...}

class PropertyWithRelationships implements IProperty 
{
    ...passthrough properties to satisfy Property interface

    public POCOProperty Property;
    public PropertyTypeWithRelationships PropertyType ;
}

class PropertyTypeWithRelationships implements IPropertyType  
{
    ...passthrough properties to satisfy PropertyType interface

    public POCOPropertyType PropertyType;
    public POCOPropertyTypeMetadata[] Metadata;
}

Il mio tentativo in un diagramma:

Esempiodicorrente(C#,manondovrebbeimportaretroppo)classe:

publicclassPropertyTypeRecord:IPropertyType{//asI'moverwritingequalsoperatorasI'mfollowingtheconvention//thatimmutabletypesareequalifthedataisthesameprivateinthashCode;publicGuidID{get;privateset;}publicGuidChangeId{get;privateset;}publicDateTime?ChangeDate{get;privateset;}publicstringName{get;privateset;}publicDataTypeDataType{get;privateset;}publicUpdateTypeUpdateType{get;privateset;}publicGuidElementTypeId{get;privateset;}publicPropertyTypeRecord(Guidid,GuidchangeId,DateTime?changeDate,stringname,DataTypedataType,UpdateTypeupdateType,GuidelementTypeId){ID=id;ChangeId=changeId;ChangeDate=changeDate;Name=name;DataType=dataType;UpdateType=updateType;ElementTypeId=elementTypeId;hashCode=Hashing.GetStableHashCode($"PropertyTypeRecord{ID}{ChangeId}{ChangeDate}{DataType}{UpdateType}{ElementTypeId}");
    }

    ... Overwriting of equals & gethashcode...
}