WPF: Welche Datenbindung verwenden?

Question

Hallo zusammen, dies ist eher keine Frage sondern Inputbox.

Vieles geht ja von meinen geliebten WinForms mit DGV´s in Richtung WPF.
Kann man mir sagen welche Art der Datenbindung am besten wäre?
Bisher befülle ich meine "Container" als Designer-gebundene DataSets, das ist bei Stammdaten immer super.
Bei Read-Only Abfragen per SQL im Quellcode mit diversen Filtern.

Bei Änderungen (insert/update) habe ich aber immer zu knabbern, auch wenn das mit den Grids ganz gut geht.
In der Regel ist es aber Code-behind-Form oder kleine Klassen, die ich mir dann zusammenbaue.

Warum sollte ich auf MVVM oder ähnliches umsteigen?
Oder was wäre besser.??

btw.: Zur zeiit konzentriere ich mich auf dem Xaml-Code und versuche den meistens ohne Designer selbst zu schreiben.
Die Datenbindung an andere UI-Elemente!  gelingen mir schon recht gut. Datasets zur GUI gehen auch.

Das ist ja aber wohl der Punkt, wo ich den Zwischenlayer einbauen sollte.

Tante Google gibt mir viel blabla dazu, vielleicht habt ihr eine Zündung für mich.

Danke Raimo

Answer 1

Hi Raimo,
mit WPF kannst Du es erst einmal genau so machen wie mit Windows Forms: im DataSource Explorer DataSet auswählen, DataGrid festlegen und rüberziehen. Ob Du damit langfristig glücklich wirst, ist ein anderes Thema.

Wenn Du schon den Aufwand des Umstiuegs auf WPF betreibst, solltest Du gleich noch an MVVM denken. Mit MVVM kannst Du Ansicht und Programmlogik vollständig trennen. Das ist zwar anfänglich etwas mehr Aufwand, lohnt sich aber später, wenn irgendwelche Anpassungen der Ansichten erforderlich werden. Zusätzlich ermöglicht die Trennung, die Logik automatisch zu testen (z.B. mit Unit-Testprojekten).

Das typische einfache MVVM-Projekt hat 3 Layer: Ansicht, ViewModel (Geschäftslogik) und Model (Datenbereitstellung und -ablage). Diese 3 Layer kann man in unterschiedlichen Projekten (oder sollte man der Übersichtlichkeit halber mindestens in Ordnern) ablegen.

Bezüglich Datenbindung ist in WPF die Bindung der Eigenschaften der Oberflächen-Elemente an Eigenschaften einer ViewModel.Instanz das Typische (im MVVM-Entwurfsmuster). Natürlich kann man aus dem CodeBehing direkt auf die Oberfläche zugreifen, was dann aber die Wartbarkeit enorm verschlechtert.

---

--
Viele Grüsse
Peter Fleischer (MVP Reconnect, Partner)
Meine Homepage mit Tipps und Tricks

Answer 2

Danke Peter,

das ist aber genau meine Frage: Warum MVVM und was ist das genau?

Wenn ich ein Stammblattt nehme:Name,Vorname,[...],Straße,PLZ,Ort...
Ich nehme meine Person-Klasse und binde die an meine frmStammdaten, txtVorname.Text=clsPersonBlabla.Vorname. usw..

Wo ist jetzt der Unterschied und was will mir (im ReadOnly Stammdaten-Anzeige) dieses dauernde NotifiyChanged INotifyChanged bringen?

Was ist daran anders oder neu? Ich wechsel de Datensatz und die Anzeige wird refreshed/updated

----

"Bezüglich Datenbindung ist in WPF die Bindung der Eigenschaften der Oberflächen-Elemente an Eigenschaften einer ViewModel.Instanz das Typische (im MVVM-Entwurfsmuster)"

----

Just dieses hätte ich gerne mal erklärt bekommen. Ist meine "ViewModel.Instanz" meine clsPerson?

Immer noch verwirrt

Raimo

Edit: Oder ist die Bindung "an sich im Xaml" der Punkt?

Answer 3

Hi Raimo,
MVVM ist ein Entwurfsmuster, genau wie auch MVP bzw. MVC. MVVM und WPF passen sehr gut zusammen, da eine vollständige Trennung von Design und Logik möglich ist.

Das NotifyPropertyChanged brauchst Du nur, wenn die Änderung des Wertes einer Eigenschaft dem an die Eigenschaft gebundenen Verbraucher - z.B. Ansicht - mitgeteilt werden soll. Solch eine Änderung kann entstehen, wenn sich der Zustand der Geschäftslogik ändert, z.B. durch Aktivitäten des Bedieners. Beispielsweise gibt Bediener einen bestimmten Wert in eine TextBox ein und die Geschäftslogik entscheidet, dass z.B. eine Hintergrundfarbe zu ändern ist, oder ein Panel sichtbar/unsichtbar zu machen ist.

Wenn Du nur eine einmalige Ausgabe brauchst (ReadOnly), dann braucht das gebundene Datenobjekt kein NotifyPropertyChanged. Aber schon, wenn in einem komplex gebundenen Steuerelement navigiert wird und Detailanzeigen deshalb aktualisiert werden sollen, brauchst Du für die Eigenschaft, die das Datenobjekt für die Detailanzeige bereitstellt, ein NotifyPropertyChanged.

Ich vermute, dass Deine clsPerson die Typbeschreibung eines Datenobjektes ist. Die Instanzen der Datenobjekte von diesem Typ werden entweder einzeln als Eigenschaft für die Bindung in einer Detailansicht oder in einer Liste verwaltet, die dann in einer Eigenschaft für eine komplexe Bindung bereitgestellt wird.

---

--
Viele Grüsse
Peter Fleischer (MVP Reconnect, Partner)
Meine Homepage mit Tipps und Tricks

Answer 4

Hallo Raimo,

wenn Du DataSets (bzw. DataTables) verwendest so stellen sie das Model dar.

Das View Model ist wird dazwischen geschaltet, und kümmert neben der Übertragung der Daten zum Model (also z. B. der DataTable), sondern auch um alle anderen Dinge, wie z. B. der Speicherlogik: Muss / Kann die Datenzeile gespeichert werden und stellt dafür die notwendigen Methoden, wie ein Speicher Befehl (via ICommand) bereit.

Die View am Ende ist die Darstellung, also ein Window, Page oder UserControl.

Sinn und Zweck des Ganzen ist es vom Code Behind weg zu kommen, wie es bei Windows Forms üblich war. Dort war der Code i. a. an Event Handler gekoppelt, die man nur durch Aufruf des Formulars testen konnte. Ein View Model kann man idealerweise unabhängig testen, ohne eine Benutzeroberfläche zu haben, und z. B. mit Unit Tests sicherstellen, dass die Logik funktioniert.

Umfangreicher beschreibt es Josh Smith in WPF-Anwendungen mit dem Model-View-ViewModel-Entwurfsmuster.

Gruß Elmar

Answer 5

Danke Euch beiden,

Elmar danke ich besonders für den Link, ich selbst habe keine vernünftige Übersetzung gefunden; also keine!

Peter: Dieser Satz ist gut: "MVVM ist ein Entwurfsmuster, genau wie auch MVP bzw. MVC. MVVM "
da bin ich bei Dir, ich mag das alles sehr. Mitunter habe ich das schon im Internet gesehen. War aber nichts anderes als...

!!Lagere Deine Routinen und Funktionen weit weg von Deinem CommandButton_Click !!

Ich (lass) generiere aus Tabellen(spalten) gerne erstmal Klassen, die dann zusammengestrichen und oder validiert werden. Das war schon bei Excel so - falls der Kunde bezahlt hat/wollte

Bin ich da jetzt falsch?

Wo ist der Unterschied zwischen den von Peter genannten Patterns?

Gruß Raimo

Answer 6

O.K.

Ich werde ein oder zwei Kundenprojekte mal hochziehen.
Bezahlt wird das zwar nicht aber der Lerneffekt macht es wohl wett.

Im Advent ist eher wenig zu tun.

Answer 7

Hi Raimo,
als Überblick zu den Entwurfsmustern habe ich auf meiner Homapge einen Beitrag: Wie sieht prinzipiell MVVM in WPF aus? Er ist zwar zu VB.NET, kann aber vielleicht etwas helfen. Alles nur zu reduzieren auch "Code weit weg ...", ist etwas zu kurzscihtig. Niemand hindet Dich daran, Code und Design zu mixen und alles ohne separate Klassen im CodeBehind zu machen.

Wie Du die Typen der Datenobjekte programmierst, ist völlig unahängig von WPF und MVVM. Da bist du nicht falsch (blödes Deutsch). Schnell und einfach geht es mit dem Entity Framework, sowohl die Erzeugung der Typen als auch das Laden und Verwalten der Datenobjekte.

---

--
Viele Grüsse
Peter Fleischer (MVP Reconnect, Partner)
Meine Homepage mit Tipps und Tricks