Alkasel ha scritto:
In realtà non uso EntityFramework bensì uso Npgsql per fare le query e poi creo manualmente gli oggetti C# a partire dai dataset restituiti dalle query.
Non conosco questa libreria/framework, ma se gli oggetti C# sei tu a crearli, puoi decidere tu fino a quando "inoltrarti" nell'alberatura degli oggetti che produci a seguito della query.
Alkasel ha scritto:
Quindi dici che avere delle dipendenze circolari può andar bene in un caso del genere e non sia necessariamente un male?
In genere, in EF ma anche in altri ORM, il problema non è nelle "dipendenze circolari" quanto più nella loro risoluzione a runtime.
Mi spiego peggio. Se hai un oggetto che fa riferimento ad un altro oggetto (o ad una lista di altri oggetti), questo in genere non è un problema; se gli oggetti della lista contengono di nuovo un riferimento all'oggetto originale, occorre determinare se questo è lecito in quanto, in fase di serializzazione, questo verrà serializzato due volte... una volta al primo livello e una volta all'ultimo.
In genere, il problema vero si riscontra quando i valori di queste "proprietà di navigazione" (cioè proprietà di un oggetto che caricano dinamicamente l'elemento della tabella correlata, il quale contiene altre proprietà che caricano di nuovo l'oggetto di partenza, e così via) vengono gestite automaticamente dal framework/ORM di turno: esso non è in grado di fermarsi da solo e recupera in cascata tutti gli oggetti e le loro dipendenze, e se i secondi fanno riferimento ai primi, il giro prosegue praticamente all'infinito, fino al sollevamento di una eccezione appropriata.
In conclusione, se invece i dati li carichi tu, puoi decidere in quel momento quanto scendere nella gerarchia a seconda dell'operazione: nel momento in cui il serializzatore trova un oggetto che referenzia un altro, caricherà anche quest'ultimo, e se quest'ultimo ne dovrebbe referenziare un altro ancora, oppure quello di partenza, deve essere valorizzato a
null affinché il serializzatore si fermi.
Ciao!