2009-12-19 5 views
0

J'utilise Fluent NHibernate/Automapping et j'ai une classe qui a une collection, et chaque élément de cette collection a sa propre collection.Quels sont les inconvénients de garder le parent comme une propriété de l'enfant dans Fluent NHibernate?

public class A 
{ 
    public virtual IList<ClassB> Items { get; set; } 
} 

public class B 
{ 
    public virtual IList<ClassC> ChildItems { get; set; } 
} 

Ceci est lié à this question, qui n'a jamais été répondu, mais a été résolu par l'OP en gardant l'objet parent sur l'objet enfant et marquer comme non nul. Est-ce la seule façon de définir une clé étrangère comme non nulle dans Fluent NHibernate? Probablement une question stupide, mais il n'y a aucune raison pour que je sache jamais quel est l'objet parent, donc avoir ces propriétés serait inutile. Si c'est le seul moyen, y a-t-il des inconvénients à le faire? Serait-il même la peine si mon code pouvait simplement gérer les relations à la place?

Répondre

0

En supposant que vous utilisez couramment les correspondances au lieu de AutoMapping, vous pouvez utiliser dans votre fichier de mappage:

HasMany(x => x.ChildItems).Not.Null();