LINQ-Wrapper-Klassen an Controls binden?

21/02/2009 - 01:34 von Alexander Mueller | Report spam
Hallo

wir verwenden in einem Projekt LINQ-To-SQL. Dabei werden
bekanntermassen Tabellen auf LINQ-Wrapper-Klassen gemappt.

Ein Kollege meinte nun, man sollte Objekte dieser Klassen nicht direkt
an (WPF-)Controls binden, um den Daten-Inhalt anzuzeigen (z.B das
Ergebnis einer Query als ItemsSource),
Das sei eine Microsoft-Best-Practice.

Stattdessen sollte man eine zweite, "normale" Klasse definieren, die
quasi dieselben Attribute besitzt, die Daten von der LINQ- in die zweite
Klasse kopieren und dann diese Objekte zur Anzeige binden.

Das kommt mir vollkommen sinnfrei, umstàndlich und unverstàndlich vor.
Ist da was dran?
Gibt es ein Problem, wenn man bspweise ein Attribut aus einer
LINQ-Klasse readonly an eine Spalte eine WPF-TK-DataGrid bindet?

Ich hab da bisher nix seltsames entdeckt?

Alle hints wilkommen,

MfG,
Alex
 

Lesen sie die antworten

#1 Peter Fleischer
21/02/2009 - 09:18 | Warnen spam
"Alexander Mueller" schrieb im Newsbeitrag
news:499f4c34$0$31337$

wir verwenden in einem Projekt LINQ-To-SQL. Dabei werden
bekanntermassen Tabellen auf LINQ-Wrapper-Klassen gemappt.

Ein Kollege meinte nun, man sollte Objekte dieser Klassen nicht direkt
an (WPF-)Controls binden, um den Daten-Inhalt anzuzeigen (z.B das
Ergebnis einer Query als ItemsSource),
Das sei eine Microsoft-Best-Practice.



Hi Alexander,
bei einer einfachen einschichtigen Anwendung, die Daten nur an einer Stelle
zur Anzeige benötigt, ist es besser, den Iterator direkt der ItemsSource zu
übergeben, damit sich das Steuerelement die Daten in den implizit erstellten
Datenpuffer holen kann.

Bei komplexeren mehrschichtigen Anwendungen ist es recht umstàndlich, mit
dem Iterator in der Bussinesschicht zu arbeiten. Da macht sich ein separater
Datenpuffer im Client besser. Wenn dann noch Teilabfragen erforderlich
werden, wird erneut bei der Datenbank nachgefragt, anstelle die Abfrage über
die bereits geladene Datenmenge auszuführen.

Stattdessen sollte man eine zweite, "normale" Klasse definieren, die
quasi dieselben Attribute besitzt, die Daten von der LINQ- in die zweite
Klasse kopieren und dann diese Objekte zur Anzeige binden.



Bei etwas umfangreicheren Anwendungen ist das in den meisten Fàllen besser.
Wie willst du andernfalls mit den Daten arbeiten - jedes Mal die Datenbank
fragen?

Das kommt mir vollkommen sinnfrei, umstàndlich und unverstàndlich vor.
Ist da was dran?



Das hàngt vom Anwendungsfall ab. Wie immer, wird es für verschiedene
Umgebungsbedingungen unterschieliche optimale Lösungen geben.

Gibt es ein Problem, wenn man bspweise ein Attribut aus einer LINQ-Klasse
readonly an eine Spalte eine WPF-TK-DataGrid bindet?

Ich hab da bisher nix seltsames entdeckt?



Schau dir mal mit dem Profiler an der Datenbank an, was beispielsweise
passiert, wenn eine LinQ auf das Ergebnis einer anderen LinQ abgesetzt wird,
beispielsweise so:

Dim dc As New DataClasses1DataContext
Dim res1 = From r In dc.Tab1s
Me.lv1.ItemsSource = res1
Dim res2 = From r In res1 Where r.ID > 2
Me.lv2.ItemsSource = res2

Wenn du jetzt eigene Objekte (z.B. ein typisiertes DataSet) hàttest,
könntest du alles im Client machen und dir den Netzwerkverkehr sparen.

Viele Grüsse
Peter

Ähnliche fragen