Una relazione è per sua natura bidirezionale. Quello che non è sempre bidirezionale è la sua rappresentazione nel domain model. Prendiamo ad esempio la relazione tra clienti e ordini. Avere a disposizione il cliente di un ordine ha senso, ma ha senso avere a disposizione la lista degli ordini di un cliente? la risposta esatta come sempre è.... dipende. Ora non voglio disquisire sulla validità o meno della relazione ma su come Entity Framework affronta il problema.

Per default, il wizard si accorge della relazione tra le tabelle e genera un domain model dove le relazioni tra le classi sono bidirezionali, quindi un ordine ha la relazione verso il cliente e il cliente ha una relazione verso gli ordini. Supponiamo che non ci sia utile in alcun modo la relazione tra cliente e ordine. La logica vuole che questa sia eliminata. Il primo problema è che il designer non lo permette; bisogna andare a mano nel codice ed eliminare la proprietà Ordini dalla classe Cliente e nel conceptual model del file di mapping eliminare il riferimento alla proprietà cancellata ed il gioco è fatto. Il secondo problema risale a LINQ to Entities. Abbiamo bisogno della proprietà Ordini per fare le nostre query? In tutti i progetti che ho seguito la risposta è stata no. Grazie al fatto che comunque l'ordine mantiene la proprietà Cliente si riesce a risalire a qualunque dato di cui si ha bisogno. L'unico vero problema sono le query generate a run-time. La regola numero uno è che bisogna sempre vedere le query generate per evitare problemi.

Comunque per ora la mia linea guida è quella di non creare proprietà inutili che complicano solo la vita.

Stay tuned...