"Ajout d'une ligne enfant à la collection enfant du parent" v.s. "ajouter un enfant à la collection enfant de datacontext"

Question

Je vais comparer 2 scénarios pour ajouter des lignes Rsvp. Lequel préférez-vous en production?

---

Méthode 1: Ajout d'un nouvel objet Rsvp à la collection de Rsvp de datacontext

Rsvp r = new Rsvp(); 
r.AttendeeName = "xport"; 

r.DinnerId = 1;//there will be an exception if it is set to a Dinnner object that does not exist. 

entities.Rsvps.AddObject(r); 

entities.SaveChanges(); 

Nous aurons une exception si nous essayons de mettre DinnerID à un objet dîner qui n'existe pas. Ce comportement est cohérent et direct.

---

Méthode 2: Ajout d'un nouvel objet Rsvp à propriétés d'un objet Dîner de rsvps

Rsvp r = new Rsvp(); 
r.AttendeeName = "xport"; 

r.DinnerId = 10000;//this Dinner does not exist! 

Dinner d = entities.Dinners.First(x => x.DinnerId == 1); 

d.Rsvps.Add(r); 

entities.SaveChanges(); 

Les DinnerID de propriétés de clé étrangère d'un objet Rsvp peut être réglé à un nombre quelconque. Lorsque cet objet Rsvp est ajouté à la collection Rsvps d'un objet Dinner, le DinnerId sera remplacé en mode silencieux. Exemple ci-dessus montre DinnerId est défini sur 10000 qui est un Id d'un objet Dinner qui n'existe pas. Est-ce un comportement inévitable?

Answer 1

Définitivement la méthode 2.

Pourquoi? Parce qu'un Rsvp ne peut pas exister sans un Dinner. Dans cette relation, dîner est le parent - et si nous devions créer un dépôt, nous créerions un DinnerRepository (comme dîner est la « racine globale » en termes DDD)

En ce qui concerne votre note - oui, c'est un comportement évitable - ce que vous devez faire est de ne pas exposer les clés étrangères sur le modèle. C'est une option disponible lorsque vous créez/mettez à jour votre modèle.

De cette façon, les relations doivent être créées/modifiées par l'entité:

Rsvp r = new Rsvp(); 
r.AttendeeName = "xport"; 
r.DinnerId = 10000; // this throws a compiler error. good! we do not want people tinkering with FK's. 
Dinner d = entities.Dinners.First(x => x.DinnerId == 1); 
d.Rsvps.Add(r); // this is the correct way to add a RSVP 
entities.SaveChanges(); 

En d'autres termes - la seule façon de créer/modifier un Rsvp est par un dîner - et la propriété FK ne peut pas être modifié .

Ce qui est logique.