Hallo,
ich habe folgende Situation

class SUB
{
 string name;
}

class P1
{
 SUB sub;
}

class P2
{
 List<SUB> subs;
}

Kann nhibernate sowas abbilden oder wie könnte ich das ganze umgehen?

Händisch würde ich das mit je einer Zwischentabelle p1_sub und p2_sub lösen.

ja sowas kann nhibernate abbilden.

das erste ist eine 1:1 und das zweite eine 1:n relation

edit: möglicherweise ist meine erklärung unzureichend:
nhibernate macht dann eine 1:n relation in der datenbank, was aber komplett von dem framework verwaltet wird. für dich macht das objekttechnisch kein unterschied.

ps: das einzige was ich bei nhibernate echt nicht empfehlen kann ist eine direkte n:m relation ohne zwischenobjekt(mappingobjekt).

LLBLGEN kann das auch abbilden.

www.llblgen.com

Zitat von Rushmore

LLBLGEN kann das auch abbilden. www.llblgen.com

hört sich an wie schleichwerbung ^^

mal im ernst. was für ein or-mapper kann das nicht abbilden?
wenn es einen gibt der das nicht schafft dann darf er sich meiner meinung nach nciht or-mapper schimpfen......

Danke für die Antworten.
Ich frage weil ich bei einigen schon gsehen habe, dass ein HasMany mit einem BelongsTo seitens der SUB "gepaart" werden muss was dann nichtmehr funktioniert mit der 1:n beziehung


/edit: was meinst du mit mappingobjekt? Eine Weiter Klasse von mir mit 2Properties SUB und P2 ? und dann in P2 ne List<MappingObjekt> ?

bei einer n:m beziehung braucht die datenbank eine zwischentabelle (mappingtabelle) und das sollte man objektorientiert auch mit einem (MappingObject) abbilden (quasi in zwei 1:n aufsplitten)

Ja, in der Datenbank ist mir das klar. Nur, wie ich das objektkorientiert abbilden soll steh ich auf dem Schlauch. Wo wird die Referenz auf das Mapping Objekt gehalten?

beispiel:

datenbank:

parent 1:N ParentChilds N:1 child

classen:

class parent
{
List<ParentChilds>...
}

class child
{
List<ParentChilds>
}

class ParentChilds
{
parent...
child...
}


edit:

somit können kinder mehrere eltern besitzten (mutter und vater z.b.) und eltern können mehrere kinder besitzen (sohn und tochter z.b.) und jeder weiß wer seine kinder und seine eltern sind.

die unschöne möglichkeit bzw. nicht zu empfehlende möglichkeit ist:
class parent
{
List<child>
}

class child
{
List<parent>
}

damit hat nhibernate manchmal echte probleme.

Ok. Danke. Ist leider nicht unbedingt schön parent. children[0].child.irgendNenProperty

korrekt. es ist etwas umständlicher aber das framework arbeitet damit besser.

Auch wenn die Klassenstruktur nicht so schön ist, würde ich persönlich dazu tendieren, bei Objekten, die die in einer Datenbank persistiert werden können nicht zu vererben. Egal was man mit den Objekten machne möchte, Hinzufügen, ändern ,oder löschen, es muss immer auf mehrere Tabellen zugegriffen werden. Ich würde diese Felder dann lieber redundant in den Datenbank-Tabellen speichern.

Bei kleineren Applikationen, wo die Vererbungshirarchie nicht so stark ist, ist dasn alles noch keine Problem, aber wenn die Vererbungs extrem gross wird, wird auf immer mehr Tabellen zugegriffen. Gerade bei aktualisierungen kann das dann schon etwas länger dauern. Das ist dann der Moment, wo O/R Mapper Ihre schwächen haben.

Sie haben dann zwar eine sehr schöne Struktur. Es lässt sich mit vernünftigen Objekten arbeiten, aber das schreiben der Daten dauert einfach zu lange.

Es sollte daher wohl überlegt sein, ob die Klassen, die die Informationen der Datenbanken verwalten sollen stark verschachtelt sind.

Hallo,
vielen Dank nochmal für die Antworten.
Was mich noch interesiert, wie macht man das am besten, zu prüfen ob es veränderungen am Objekt gibt um eine Abfrage machen zu können ob gespeichertw erden soll oder nicht?

Eine Möglichkeit die mir einfällt währe das INotifyPropertyChanged Interface. Aber was macht man da mit Listen(also list<t>) Properties?

Ich bin mir nicht ganz sicher, ob es eine Patentlösung gibt.

Grundsätzlich würde ich es folgendermassen machen ( oderhabe es sogar so gemacht),
dass Du deinem Object eine eigentschaft besitzt, die den Status wiedergibt. Dafür würde ich ein Enum hernehmen, mit den folgenden einträgen:
Created
Unchanged
Modifield
Deleted
...

Bei jedem setzen eines Properties prüfst Du ob es den Status unchanged hat und sich der Wert geändert hat. Ist dies der Fall, setzt du den Status von Unchanged auf Modifield.
Somit weisst du bei der persistierung, was Du mit dem Object machen musst.

Wenn Du mehr wissen möchtest schau doch mal unter Invist nach. Da wird mittels Code-Generator genau so etwas gemacht.

Nabend,

Hatte auch das Problem, dass ich ermitteln musste, ob mein Objekt geändert wurde.
Ich habe die Originalwerte meiner Properties in meinen Objekten (um "Rückgängig" ausführen zu können) und prüfe beim Speichern jedes einzelne Property, ob noch der Originalwert drin ist. Zusätzlich kann/muss man eine Methode implementieren, die erweiterte Eigenschaften überprüft (Listen, etc.).

Für Listen arbeite ich gerade an eine BufferedList<>, die überprüfen kann, ob neue Objekte hinzugefügt wurden oder Objekte entfernt wurden (und auch "Rückgängig" implementiert).

Und ich hab mal von einem Interface INotifyCollectionChanged gehört, da weis ich aber noch nichts weiteres.

Gruß
Juy Juka

INotifyPropertyChanged sollte in jedem BusinessObject implementiert werden,
genauso wie IEditableObject und IDataErrorInfo.

INotifyPropertyChanged:
Wenn du bei echten Änderungen eben das hierfür nötige PropertyChanged
implementierst und aufrufst, kann eine BindingList z.B. die gebundenen
Controls benachrichtigen.

IEditableObject:
Dann kann auch z.B. ein Grid CancelEdit aufrufen.

IDataErrorInfo:
Versorgt z.B. den ErrorProvider oder das Grid gleich mit den Fehlermeldungen.

Wenn du dann noch im PropertyChanged das Validieren machst, kann das
sofort, beim editieren über den ErrorProvider angezeigt werden.

Deine Eingabemasken werden deutlich einfacher dadurch, und du kannst
die Businessschicht die arbeit dann machen lassen, die leider immernoch
zu häufig in der UI gemacht wird.

Ach und BindingList liefert bereits ereignisse wenn die Collection sich ändert.

Hallo,

Nhibernate macht doch LazyLoad und meines errachtens wird auch nur das aktualliesiert was zu aktuallisieren ist.

Hallo,
welche Interfaces sind bei WPF für eigene Objekte denn "sinnvoll" bzw von nöten?