Laden...

o/r mapping

Erstellt von _daniel_ vor 16 Jahren Letzter Beitrag vor 15 Jahren 2.437 Views
_
_daniel_ Themenstarter:in
227 Beiträge seit 2006
vor 16 Jahren
o/r mapping

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.

Gelöschter Account
vor 16 Jahren

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).

R
69 Beiträge seit 2006
vor 16 Jahren

LLBLGEN kann das auch abbilden.

www.llblgen.com

Gelöschter Account
vor 16 Jahren

LLBLGEN kann das auch abbilden.


>

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......

_
_daniel_ Themenstarter:in
227 Beiträge seit 2006
vor 16 Jahren

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> ?

Gelöschter Account
vor 16 Jahren

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)

_
_daniel_ Themenstarter:in
227 Beiträge seit 2006
vor 16 Jahren

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?

Gelöschter Account
vor 16 Jahren

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.

_
_daniel_ Themenstarter:in
227 Beiträge seit 2006
vor 16 Jahren

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

Gelöschter Account
vor 16 Jahren

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

M
110 Beiträge seit 2007
vor 16 Jahren

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.

Gruss

Mirko

Mappen statt hacken mit Invist , dem .NET O/R Mapper - Code Generator

_
_daniel_ Themenstarter:in
227 Beiträge seit 2006
vor 16 Jahren

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?

M
110 Beiträge seit 2007
vor 16 Jahren

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.

Gruss

Mirko

Mappen statt hacken mit Invist , dem .NET O/R Mapper - Code Generator

2.187 Beiträge seit 2005
vor 16 Jahren

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

F
10.010 Beiträge seit 2004
vor 16 Jahren

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.

B
122 Beiträge seit 2004
vor 16 Jahren

Hallo,

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

_
_daniel_ Themenstarter:in
227 Beiträge seit 2006
vor 15 Jahren

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