Ich bemühe mich, den besten Weg zu finden, 1: 0,1-Beziehungen zu modellieren ("kann einen haben" oder "hat höchstens einen"). Ich glaube, das nennt man Z-Kardinalität.
Angenommen, ich habe zwei Klassen Widget und WidgetTest . Nicht alle Widgets sind getestet und der Test ist destruktiv, so dass es höchstens einen WidgetTest pro Widget geben kann. Nehmen Sie außerdem an, dass es unangemessen ist, die WidgetTest-Felder zu Widget hinzuzufügen.
Ich möchte meine öffentliche Schnittstelle:
%Vor%Modell 1: Widget hat eine WidgetTest-Eigenschaft und in der Datenbank hat die Widget-Tabelle einen eindeutig eingeschränkten Fremdschlüssel für WidgetTest. Mein DBA argumentiert, dass dies zulässt, dass ein WidgetTest-Datensatz ohne ein Widget existiert.
%Vor%Modell 2: Widget verfügt über eine private Sammlung von WidgetTest und erzwingt die Beziehung von 0,1 durch Hinzufügen oder Entfernen eines einzelnen Objekts aus der Sammlung, die von einer öffentlichen WidgetTest-Eigenschaft gesteuert wird. Die Datenbank modelliert dies als 1: m, wobei WidgetTest einen eindeutig eingeschränkten Fremdschlüssel für Widget hat. Ich argumentiere, dass dies bedeutet, das Modell an das Datenbankschema anzupassen (d. H. Mehr Arbeit für mich).
%Vor%Welches Modell ist besser? Was ist mit NHibernate einfacher zu erreichen? Oder gibt es einen dritten Weg?
Bearbeiten ... Hier ist, womit ich endete:
%Vor%Mein Ansatz bestand darin, eine Eins-zu-Viele-Beziehung in den Zuordnungen zu modellieren, aber die "Viele" auf ein einzelnes Element zu beschränken. Dies ermöglicht die optionale Eins-zu-Eins-Funktion und garantiert außerdem, dass Ihre WidgetTest-Instanz beim Speichern des Widgets beibehalten wird. Zum Beispiel:
%Vor%Wenn Sie sagen "Nehmen Sie an, dass es unangemessen ist, die WidgetTest-Felder zu Widget hinzuzufügen", meinen Sie das in Ihren Domänenobjekten oder in der Datenbank. Wenn Sie sich darüber freuen, dass sich die Felder in der gleichen Tabelle in der Datenbank befinden, wie wäre es mit WidgetTest als Widgetkomponente? Lassen Sie die NHibernate-Zuordnungsdatei folgendermaßen aussehen:
%Vor%Geben Sie die Tabellenstruktur:
%Vor%Wenn Sie trotzdem die von Ihnen angegebene öffentliche Schnittstelle verwenden würden, würde WidgetTest jedoch zu einem Wertobjekt werden, das Sie möglicherweise nicht benötigen.
Die Antwort von NW. kann zu der Ausnahme " A collection with cascade=”all-delete-orphan” was no longer referenced by the owning entity instance " führen.
Dies ist der Fall, wenn Sie inverse="true" und cascade="all-delete-orphan" in Ihrer Zuordnungsdatei verwenden.
Dies liegt daran, dass die Antwort von nw. jedes Mal, wenn der get -Accessor aufgerufen wird, eine neue Liste erstellt und nichts mit der über den set -Accessor übergebenen Liste tut. Daher hat NHibernate nicht die IList<WidgetTest> -Referenz, die beim Erstellen des Objekts ursprünglich übergeben wurde, und kann nicht mit der Kaskade fortfahren.
Um dies zu beheben, müssen wir etwas mit dieser IList<WidgetTest> -Referenz tun und darauf achten, dass die Referenz nicht entfernt wird.
Zuordnung:
%Vor%Inspiration für die Verbesserung:
Tags und Links oop nhibernate nhibernate-mapping