vedo un sacco di esempi sull'uso di codice EF prima con pocos che mostrano qualcosa di simile:Devo tenere le chiavi esterne in sincronia con i riferimenti quando si utilizza pocos
public class Post
{
public int PostId { get; set; }
public string Title { get; set; }
public string Content { get; set; }
public int BlogId { get; set; }
public virtual Blog Blog { get; set; }
}
Ora, guardate la proprietà Blog
. Non dovrebbe essere così, invece:
private Blog blog;
public virtual Blog Blog
{
get
{
return blog;
}
set
{
blog = value;
if (blog != null)
{
BlogId = blog.BlogId;
}
}
}
Voglio dire, dal momento che già sta "inquinare" il modello con la chiave esterna, non dovresti almeno mantenerlo sincronizzato con il riferimento? Oppure non dovresti fare affidamento su BlogId
durante la lettura dei dati (ad esempio, come se volessi sapere se uno specifico BlogId
è in un elenco). O forse c'è una proprietà magica su DbContext
(come KeepForeingKeysPropertiesSyncronizedWithReferences
) che lo fa a me e io sono l'unico programmatore triste che si preoccupa di questo? O sono paranoico? (Anche, mi dispiace per il mio povero inglese)
EDIT spiacenti per questo - è stato davvero una domanda stupida. Stefan ha ragione, EF lo fa davvero per te. Non ho visto questo perché i riferimenti che stavo passando sono stati caricati con AsNoTracking()
. Solo in questa condizione avremo un riferimento con ID e il campo chiave esterna sarà 0. Finché si passa un riferimento già presente nel contesto, dovrebbe funzionare.
non conoscono EF, ma aveva si è utilizzato NHibernate che non mettereste nella proprietà BlogId a tutti. – erikkallen
Penso che avere la possibilità di usare il BlogId sia bello, quindi non ho bisogno di avere un riferimento sul blog e comunque posso salvare l'associazione. Sono solo confuso su come mantenerlo sincronizzato - per me sembra la cosa più ovvia da fare ma non ho mai visto qualcuno farlo, quindi forse ho sbagliato: / – user1526627