Hallo,
ich bin mir völlig im klaren darüber, dass ich jetzt wohl ein paar Leute verärgern werden, die fest der Ansicht sind, dass die Codebehind-Datei bei der Benutzung des MVVM-Patterns verboten gehört. Aber ich (und sehr, sehr viele andere) sind der festen Ansicht, dass das Codebehind in manchen Fällen sogar benutzt werden sollte, um das MVVM-Prinzip beizubehalten, was ich im Nachfolgenden erläutern werde. Aber zuerst einmal möchte ich euch noch einmal klar machen, was das MVVM eigentlich ist:
View <-> ViewModel <-> Model
Was sehen wir? Der View und das ViewModel kommunizieren, meistens über DataBinding. Zusätzlich dazu kommunizieren das ViewModel und das Model.
Was ist der View?
Alle durch die Grafische Benutzeroberfläche (GUI) angezeigten Elemente. Es bindet sich an Eigenschaften des ViewModel, um Inhalte darzustellen und zu manipulieren sowie Benutzereingaben weiterzuleiten.
Was ist das ViewModel?
Das ViewModel beinhaltet die UI-Logik (Model der View) und dient als Bindeglied zwischen View und obigem Model. Einerseits tauscht es Information mit dem Model aus, ruft also Methoden oder Dienste auf. Andererseits stellt es der View öffentliche Eigenschaftenund Befehle zur Verfügung.
Was ist das Model?
Datenzugriffsschicht für die Inhalte, die dem Benutzer angezeigt und von ihm manipuliert werden. Dazu benachrichtigt es über Datenänderungen und führt eine Validierung der vom Benutzer übergebenen Daten durch. Es beinhaltet die gesamteGeschäftslogik und ist für sich alleine durch Unit Tests überprüfbar.
Zusammengefasst bedeutet das folgendes: Der View ist alles was wir sehen, das ViewModel verarbeitet Benutzerangaben und stellt Informationen zur Verfügung. Das Model definiert die eigentliche Logik des Programms.
Wo steht jetzt, dass die Codebehind-Datei unter Anwendung des MVVMs verboten ist?
Richtig, nirgendwo. Oben steht sogar, dass sie erlaubt ist. Wieso? Gucken wir uns mal an, wie unser Codebehind-Datei von dem
Alle, die nicht wissen, was
Also haben wir gerade bewiesen, dass der View nicht nur aus der xaml-Datei besteht, sondern auch aus der xaml.cs-Datei. Versteht ihr, worauf ich hinaus will? Der View besteht auch aus der Codebehind-Datei.
Ich möchte nicht, dass ihr das falsch versteht: MVVM besagt, dass der View von der Logik getrennt werden soll. Das werden wir auch beibehalten. Es ist auch nun mal so, dass das Codebehind meistens ziemlich leer bleibt, weil eben das meiste durch das ViewModel geregelt wird. Aber so lange es keine Logik ist, sondern ausschließlich zu dem View gehört, solltet ihr die Codebehind-Datei benutzten. Sonst würdet ihr gegen das MVVM-Prinzip verstoßen. Das sagt nämlich, dass der View und das ViewModel getrennt sein sollen und das gilt für beide Richtungen.
Was gehört jetzt in die Codebehind-Datei, und was nicht?
Konkrete Beispiele für die Benutzung des Codebehinds:
(Das hat immerhin ein Microsoft-Entwickler geschrieben)
Und nochmal ein schönes Zitat, was mich ein bisschen zum lächeln bringt:
- Ihr solltet euch immer im klaren darüber sein, dass MVVM nur ein Pattern ist. Nichts weiter. Es ist ein einfaches Rezept, um ein bestimmtes Ergebnis in einer bestimmten Situation zu erhalten. Es sollte nicht wie eine Religion behandelt werden, in der Ungläubige oder Leute, die nicht mitmachen, im Fegefeuer landen (obwohl die Einhaltung des Patterns natürlich nicht schlecht ist).
Quellen:
de.wikipedia.org/wiki/Model_View_ViewModel
codekicker.de/fragen/wpf-verwe…vvm-codebehind-diskussion
stackoverflow.com/questions/20883199/wpf-mvvm-code-behind
stackoverflow.com/questions/16…ode-behind-best-practices
programmers.stackexchange.com/…nsidered-part-of-the-view
stackoverflow.com/questions/64…ehind-in-wpf-mvvm-pattern
dofactory.com/topic/1279/wpf-mvvm-code-behind-code.aspx
blog.jerrynixon.com/2012/08/mo…doing-mvvm-all-wrong.html
ich bin mir völlig im klaren darüber, dass ich jetzt wohl ein paar Leute verärgern werden, die fest der Ansicht sind, dass die Codebehind-Datei bei der Benutzung des MVVM-Patterns verboten gehört. Aber ich (und sehr, sehr viele andere) sind der festen Ansicht, dass das Codebehind in manchen Fällen sogar benutzt werden sollte, um das MVVM-Prinzip beizubehalten, was ich im Nachfolgenden erläutern werde. Aber zuerst einmal möchte ich euch noch einmal klar machen, was das MVVM eigentlich ist:
View <-> ViewModel <-> Model
Was sehen wir? Der View und das ViewModel kommunizieren, meistens über DataBinding. Zusätzlich dazu kommunizieren das ViewModel und das Model.
Was ist der View?
Alle durch die Grafische Benutzeroberfläche (GUI) angezeigten Elemente. Es bindet sich an Eigenschaften des ViewModel, um Inhalte darzustellen und zu manipulieren sowie Benutzereingaben weiterzuleiten.
Was ist das ViewModel?
Das ViewModel beinhaltet die UI-Logik (Model der View) und dient als Bindeglied zwischen View und obigem Model. Einerseits tauscht es Information mit dem Model aus, ruft also Methoden oder Dienste auf. Andererseits stellt es der View öffentliche Eigenschaftenund Befehle zur Verfügung.
Was ist das Model?
Datenzugriffsschicht für die Inhalte, die dem Benutzer angezeigt und von ihm manipuliert werden. Dazu benachrichtigt es über Datenänderungen und führt eine Validierung der vom Benutzer übergebenen Daten durch. Es beinhaltet die gesamteGeschäftslogik und ist für sich alleine durch Unit Tests überprüfbar.
Zusammengefasst bedeutet das folgendes: Der View ist alles was wir sehen, das ViewModel verarbeitet Benutzerangaben und stellt Informationen zur Verfügung. Das Model definiert die eigentliche Logik des Programms.
Wo steht jetzt, dass die Codebehind-Datei unter Anwendung des MVVMs verboten ist?
Richtig, nirgendwo. Oben steht sogar, dass sie erlaubt ist. Wieso? Gucken wir uns mal an, wie unser Codebehind-Datei von dem
MainWindow
definiert ist:Alle, die nicht wissen, was
partial
bedeutet, klicken hier.Also haben wir gerade bewiesen, dass der View nicht nur aus der xaml-Datei besteht, sondern auch aus der xaml.cs-Datei. Versteht ihr, worauf ich hinaus will? Der View besteht auch aus der Codebehind-Datei.
Ich möchte nicht, dass ihr das falsch versteht: MVVM besagt, dass der View von der Logik getrennt werden soll. Das werden wir auch beibehalten. Es ist auch nun mal so, dass das Codebehind meistens ziemlich leer bleibt, weil eben das meiste durch das ViewModel geregelt wird. Aber so lange es keine Logik ist, sondern ausschließlich zu dem View gehört, solltet ihr die Codebehind-Datei benutzten. Sonst würdet ihr gegen das MVVM-Prinzip verstoßen. Das sagt nämlich, dass der View und das ViewModel getrennt sein sollen und das gilt für beide Richtungen.
Was gehört jetzt in die Codebehind-Datei, und was nicht?
- Alles, was irgendwie mit Logik zu tun hat, gehört nicht in die Codebehind-Datei
- Events können behandelt werden, von wo aus wir Methoden im ViewModel aufrufen können
- Alles was ausschließlich mit dem View zu tun hat, Beispiele folgen
Konkrete Beispiele für die Benutzung des Codebehinds:
- Wir wollen auf das Closing-Event reagieren. Wir reagieren einfach in der Codebehind-Datei auf das Event und rufen dann im ViewModel ein paar Methoden auf, die zB. Objekte verwerfen oder Dienste beenden
- Wir wollen, dass beim Klick in eine TextBox der komplette Text markiert wird. Einfach auf das Event reagieren und den Text markieren.
- Wir wollen eine Dragbare-
ListView
hinbekommen. Dazu können wir einfach auf dasDragEnter
-Event reagieren und den Effekt setzten (e.Effects =
DragDropEffects.WhatEver
). Das gleiche gilt für dasDrop
-Event - Wir möchten ein eigenes Fenster-Design. Dazu müssen wir den Close-Button irgendwie dazu bringen, damit sich das View schließt -> Close-Event, worin wir das Fenster schließen
https://stackoverflow.com/questions/20883199/wpf-mvvm-code-behind schrieb:
MVVM is not here for you to write thousands of ugly lines of code in ViewModels, it's here to make the code testable and to introduce a separation of concerns.
http://blog.jerrynixon.com/2012/08/most-people-are-doing-mvvm-all-wrong.html schrieb:
MVVM is not an exercise to remove all the code from your XAML code behind files. Instead, MVVM intends to separate the logic you need to access and interact with your data from the logic you need to interact with your UI. For example, loading your data, validating your data, manipulating your data, and saving your data – that’s all part of the View Model. Conversely, running animations, responding to gestures, and adding the bling that makes your app stand apart – that’s part of the View.
(Das hat immerhin ein Microsoft-Entwickler geschrieben)
Und nochmal ein schönes Zitat, was mich ein bisschen zum lächeln bringt:
https://stackoverflow.com/questions/6421372/why-to-avoid-the-codebehind-in-wpf-mvvm-pattern schrieb:
One thing to remember though is that MVVM is a pattern, and a pattern is simply a recipe or prescriptionfor achieving a certain result in a certain situation. It shouldn't be treated as a religion, where non-believers or non-conformers are going to go to some purgatory (although adherence to the pattern is good if you want to avoid the purgatory of maintenance hell and code smell).
- Ihr solltet euch immer im klaren darüber sein, dass MVVM nur ein Pattern ist. Nichts weiter. Es ist ein einfaches Rezept, um ein bestimmtes Ergebnis in einer bestimmten Situation zu erhalten. Es sollte nicht wie eine Religion behandelt werden, in der Ungläubige oder Leute, die nicht mitmachen, im Fegefeuer landen (obwohl die Einhaltung des Patterns natürlich nicht schlecht ist).
Quellen:
de.wikipedia.org/wiki/Model_View_ViewModel
codekicker.de/fragen/wpf-verwe…vvm-codebehind-diskussion
stackoverflow.com/questions/20883199/wpf-mvvm-code-behind
stackoverflow.com/questions/16…ode-behind-best-practices
programmers.stackexchange.com/…nsidered-part-of-the-view
stackoverflow.com/questions/64…ehind-in-wpf-mvvm-pattern
dofactory.com/topic/1279/wpf-mvvm-code-behind-code.aspx
blog.jerrynixon.com/2012/08/mo…doing-mvvm-all-wrong.html
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „VincentTB“ ()