Listbox in einer Listbox + ItemTemplate mit Button und Eventhandler

mfG Gü

@gfoidl
Ich glaube zero_x meinte eher das es nicht viel bringt gleich bei jeden Pups auf MVVM hin zu weisen wie es in WPF oft gemacht wird, ein einfachen hinweis das man gegen ein ICommand binden kann reicht vollkommen, Pattern hin oder her.

Dazu sei auch gesagt das man auch gegen die Code Behind binden kann, oder gegen ein Controler, oder...
es gibt viele Wege.

Speziell bei MVVM sehe ich deutlich zuviel overhead für ein nutzen der praktisch nicht da ist, man kann auch binden und keine direkten UI Zugriffe haben ohne gleich die ViewModel Objekte zu implementieren, wenn man mal schaut was für kKämpfe MVVM Libraries eingehen müssen, allein schon für die Verwendung von Events.
Wenn man sich die MVVM Diagramme an sieht, Tonnen an Objekten die nur nötig sind um MVVM ein zu setzen -> der Focus liegt völlig falsch.

Hallo CSL,

korrigiere mich bitte wenn ich falsch liege denn ich beschäftige mich noch nicht so lange damit, aber

Wenn man sich die MVVM Diagramme an sieht, Tonnen an Objekten die nur nötig sind um MVVM ein zu setzen

für MVVM sind doch minimal nur 3 Objekt notwendig:1.die View 1.das ViewModel 1.und das Model

Wenn ich auf das Model (~> Daten(haltung)) verzichten kann bleiben 2 Objekte: 1x UI und 1x UI-Logik. Das ist kein unnötiger Aufwand, sondern saubere Trennung.

Ein MVVM-Diagramm ist auch nicht so kompliziert 😉

Zu MVVM-Libs kann ich (noch) nichts sagen...

mfG Gü

Das sind die Basisobjekte
Aber was ist mit Events, wenn man ein Window den DialogResult setzen will, Drag & Drop, alles Standard Aktionen die mit MVVM einiges an Arbeit erfordern.
Auch Standard Aktionen wie Synchronisieren einer List aus den Model zu einer ObservableCollection.
Alles zusätzliche arbeit die notwendig wird wenn man MVVM einsetzt.

Event holen:
Normal: EventHandler registrieren
MVVM: Ein Attached Behavior schreiben oder eine generische Klasse einsetzen

DialogResult:
Normal: Einfach this.DialogResult = true;
MVVM: http://stackoverflow.com/questions/501886/wpf-mvvm-newbie-how-should-the-viewmodel-close-the-form

Drag & Drop:
Normal: Events holen und direkt interagieren Link
MVVM: Behaviors schreiben und je nach Aktion anpassen Link

Focus in einer TextBox setzen:
Normal: Direkt this.Dispatcher.BeginInvoke(action)
MVVM: Keine Ahnung, bestimmt auch irgendwie wieder über ein Attached behavior.

Eine Liste von dynamisch erstellten UserControls in einer ListBox:
Normal: Die Controls in einer Liste im Code und die View bindet dagegen
MVVM: Da muss irgendwie wieder ein Wrapper dazwischen da die ViewModel die UserControls nicht halten darf und die UserControls alle auch eigene ViewModels bräuchten, ich hatte dafür mein UserControlsHelper.

Könnte das ewig fortsetzen.

Die Drei Objekte von dir sind wie gesagt die Basisobjekte, sobald mehrere Objekte in einer UI angezeigt werden hast du wieder Wrapper und dadurch alles *2.

Ich hatte mal ein Mittelgroßes Projekt von MVVM auf "MVC" refactored und erreichte dadurch 150 unnötige Dateien weniger, deine Deutlich einfachere Struktur (da der overhead weg fiel) und das bei gleichen Funktionsumfang.

http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx => Alter, das ist nur eine Billige TreeView, das ist Kindergarten -.-

[erledigt] Dialog schließen mit MVVM
WPF - Menu IsChecked
MVVM TabItem -> Selector.Selected Event an ViewModel übergeben
Bindingproblem, Property mit Event ändern (MVVM)
TreeView ParentItem selektieren (MVVM)

So viele Probleme nur weil Leute "dem MVVM gerecht sein wollen", hei, wacht auf, ihr habt das Ziel aus den Augen verloren, es geht nicht darum es ein Pattern recht zu machen, ein Pattern soll helfen und nicht unnötige Mehrarbeit machen.

Welchen vorteil bringt mir MVVM das es so viel Mehrarbeit rechtfertigt?
Und bitte nicht nur auf diese Frage eingehen und mein bisher geschriebenes ignorieren 😉

//Dazu: Auch ohne MVVM bekommt man eine saubere Trennung 😉 Die ViewModels sind meistens der View zugeschnitten, dann kann es auch gleich die Code Behind sein, und wenn man die sauber aufzieht ist sie genauso Testbar und Modular. Ob nun die ViewModel der Proxy ist oder die Code Behind, wayn

Hallo CSL,

von Aussagen wie

hei, wacht auf, ihr habt das Ziel aus den Augen verloren
...
Alter, das ist nur eine Billige TreeView, das ist Kindergarten -.-

kann ich gar nichts halten. Auch nicht wenn du nicht verstanden hast was in meiner vorletzen Antwort stand:

Ein Muster ist generell nie ein Muss. ... Muster sind ja nur ein Leitfaden

Aber egal...

Das sind die Basisobjekte

Ja das sind sie 😉

Einige deiner genannten Beispiele betreffen nur die UI wie zB Focus in einer TextBox setzen. Warum sollte hier auch MVVM oder irgendein anderes Verfahren zur Trennung von UI und Logik (wenn ich das in der Antwort nochmals erwähne kürze ich das mit M* ab) angewandt werden? Es gibt keinen Grund dafür denn das ist UI-Aufgabe (-> Code-Behind, Behaviour, ...)

Das "Event holen" hab ich erst verstanden als ich "Attached Behavior" gelesen habe. Das zielt ja alles auf UI ab und hat mit Logik nichts zu tun. Hier ist klarerweise kein M* notwendig.

"Drag&Drop". Im UI wird ein Element von der D&D-Quelle zur D&D-Senke gezogen und anschießend muss diese "Transaktion" in den Datenobjekten durchgeführt werden. Hier liegt doch (auch ein) klassischer Fall für die Trennung von UI und Logik vor.
In deinem verlinkten Blog erinnert mich das sehr an meine WinForms-Anfänge wo alles in der Form.cs codiert wurde. Eine Trennung von UI und Logik ist nicht zu erkennen. UI-Code und Logik-Code in der selben Klasse halte ich für nicht sinnvoll. Diese Trennung wird mMn durch die Trennung von XAML und Code-Behind nicht hergestellt. Die Code-Behind leitet immerhin von UIControl ab und ist somit eindeutig UI 😉

Für "Eine Liste von dynamisch erstellten UserControls in einer ListBox"
wenn es UCs zur Datenhaltung sind sollte das wohl auch getrennt werden und die Daten müssen eh in einer Liste im Model verwaltet werden.
Selbiges gilt für "sobald mehrere Objekte in einer UI angezeigt werden".

Ob nun die ViewModel der Proxy ist oder die Code Behind

Ein ViewModel ist kein Proxy für die UI - es gibt keine gemeinsame Basis - sondern eher ein Mediator 😉

Dass Trennung der Anliegen in mehr Code resultiert ist klar, aber ein Monolith ist auch nicht das Wahre.

Auch ohne MVVM bekommt man eine saubere Trennung

Da stimme ich dir zu. Vielleicht hast du ja bemerkt dass ich in dieser Antwort MVVM nie als Ideal dargestellt habe - immer nur die Trennung von UI und Logik. Ob MVVM das ideale Muster für WPF ist weiß ich nicht (hab noch zu wenig Erfahrung mit WPF, das ändert aber nichts an den Aussagen die ich hier mache). Es hat ja auch Nachteile (zB dass die UI fast zwangsweise WPF sein muss und nicht ein WinForms oder ASP.net sein kann). Obwohl ich mir beim Schreiben von Vor- und Nachteil fast schwer tue, denn ein Leitfaden ist so lose definiert dass es sich (fast) beliebig "verformen" lässt. Insofern sehe ich die Übergänge zwischen MVP, Presentation Model, MVVM, ... als "fast fließend" an. Bei Mustern gibt es keine harte Regeln wie in der Mathematik dass 0!=1 ist und somit kann und soll man diesen Spielraum zum Vorteil ausnutzen.

dann kann es auch gleich die Code Behind sein

Da fühle ich wieder in die WinForms-Anfänge zurückversetzt. Sorry, aber das sehe ich so.

Ich hab zufällig Ist MVVM ein Muss bei WPF Anwendungen gesehen und da finde ich deinen "Sinnenswandel" interessant.
Vor allem genau das was ich hier auch erwähnt habe:

ich kann mir nur vor stellen das die logic in der behind steckt und ui in der xaml
das ist aber keine trennung

Du wirst sicherlich die Gründe dafür haben - darauf müssen wir nicht eingehen.

Schade dass ich diesen Beitrag nicht früher gefunden habe denn der Beitrag von winSharp93 deckt sich ziemlich mit meiner Einstellung zum Thema.

Ich werde diese Diskussion aber nicht weiterführen denn wenn ich sehe wie du deine Meinung zum Thema geändert hast - wer weiß wie ich das sehen werde wenn ich mehr Erfahrung habe 😉

mfG Gü

von Aussagen wie

hei, wacht auf, ihr habt das Ziel aus den Augen verloren
...
Alter, das ist nur eine Billige TreeView, das ist Kindergarten -.-
kann ich gar nichts halten.

Ja OK, das war eventuell ein bisschen sehr reißerisch, vergessen wir das 😉

Das sind die Basisobjekte
Ja das sind sie 😉

Einige deiner genannten Beispiele betreffen nur die UI wie zB Focus in einer TextBox setzen. Warum sollte hier auch MVVM oder irgendein anderes Verfahren zur Trennung von UI und Logik (wenn ich das in der Antwort nochmals erwähne kürze ich das mit M* ab) angewandt werden? Es gibt keinen Grund dafür denn das ist UI-Aufgabe (-> Code-Behind, Behaviour, ...)

Genau da fängt es an kompliziert zu werden, denn wenn das Setzen des Focus aus dem Code heraus angetriggert wird, muss die ViewModel irgendwie der View sagen das es seine Focus Position verschieben muss, und da verschwimmt es dann etwas.

Das "Event holen" hab ich erst verstanden als ich "Attached Behavior" gelesen habe. Das zielt ja alles auf UI ab und hat mit Logik nichts zu tun. Hier ist klarerweise kein M* notwendig.

Du meinst also die View abonniert das Event in die Code Behind rein und ruft dann explizit etwas im ViewModel auf? Verletzt man damit nicht die Trennung? EIn Attached Behavior wäre die einzigste saubere Trennung wenn man eine ViewModel lose Binden will.

"Drag&Drop". Im UI wird ein Element von der D&D-Quelle zur D&D-Senke gezogen und anschießend muss diese "Transaktion" in den Datenobjekten durchgeführt werden. Hier liegt doch (auch ein) klassischer Fall für die Trennung von UI und Logik vor.
In deinem verlinkten Blog erinnert mich das sehr an meine WinForms-Anfänge wo alles in der Form.cs codiert wurde. Eine Trennung von UI und Logik ist nicht zu erkennen. UI-Code und Logik-Code in der selben Klasse halte ich für nicht sinnvoll. Diese Trennung wird mMn durch die Trennung von XAML und Code-Behind nicht hergestellt. Die Code-Behind leitet immerhin von UIControl ab und ist somit eindeutig UI 😉 Welche Logik? Die Drag&Drop Aktionen sind doch reine UI Aktionen, nur das umschieben der Objekte in den Listen, und auch das kann die View machen.

Für "Eine Liste von dynamisch erstellten UserControls in einer ListBox"
wenn es UCs zur Datenhaltung sind sollte das wohl auch getrennt werden und die Daten müssen eh in einer Liste im Model verwaltet werden.
Selbiges gilt für "sobald mehrere Objekte in einer UI angezeigt werden".

Angenommen wir haben 3 absolut unterschiedliche UserControls, diese müssten mit ViewModels versehen werden, und irgendwie mit etwas voodoo mit den Daten verbunden werden, und auch da kann es sein das das Selbe objekt in zwei verschiedene UserControls passen kann, d.h. DataTemplate anhand des Types geht nicht, das Binden der UC DataContexen gegen verschiedene ViewModels, diese ViewModels müssen die korrekten Daten bekommen .... Alles Problem die eigentlich leicht zu umgehen wären.

Ob nun die ViewModel der Proxy ist oder die Code Behind
Ein ViewModel ist kein Proxy für die UI - es gibt keine gemeinsame Basis - sondern eher ein Mediator 😉

Mit Proxy meinte ich eherdas die ViewModel zwischen Model und View vermittelt, so wird es ja auch immer beschrieben, aber lassen wir das.

Dass Trennung der Anliegen in mehr Code resultiert ist klar, aber ein Monolith ist auch nicht das Wahre.

Richtig, daher kann die CodeBehind sich um sachen kümmern die die UI betreffen, und weitere Aktionen landen dann in den entsprechenden klassen, so bleibt auch ohne MVVM die CodeBehind sehr schlank.

Ich entwickel nach einem "MVC" muster, ich setz es in quotes da es kein richtiges MVC ist, eher eine Abwandlung davon
View ist die Xaml, ist klar, und meine CodeBehind ist der Controller, die CodeBehind kümmert sich um aktionen UI betreffend, und Delegiert weitere aufgaben in verschiedene klassen. Somit habe ich meine View und meine Models problemlos getrennt.
Dort noch ein Objekt dazwischen schalten halte ich für unnötig.

Auch ohne MVVM bekommt man eine saubere Trennung
Da stimme ich dir zu. Vielleicht hast du ja bemerkt dass ich in dieser Antwort MVVM nie als Ideal dargestellt habe - immer nur die Trennung von UI und Logik. Ob MVVM das ideale Muster für WPF ist weiß ich nicht (hab noch zu wenig Erfahrung mit WPF, das ändert aber nichts an den Aussagen die ich hier mache). Es hat ja auch Nachteile (zB dass die UI fast zwangsweise WPF sein muss und nicht ein WinForms oder ASP.net sein kann). Obwohl ich mir beim Schreiben von Vor- und Nachteil fast schwer tue, denn ein Leitfaden ist so lose definiert dass es sich (fast) beliebig "verformen" lässt. Insofern sehe ich die Übergänge zwischen MVP, Presentation Model, MVVM, ... als "fast fließend" an. Bei Mustern gibt es keine harte Regeln wie in der Mathematik dass 0!=1 ist und somit kann und soll man diesen Spielraum zum Vorteil ausnutzen.

Jup, kann ich direkt zustimmen.

dann kann es auch gleich die Code Behind sein
Da fühle ich wieder in die WinForms-Anfänge zurückversetzt. Sorry, aber das sehe ich so.

Sie meine Aufführung von gerade eben, wenn du es sauber aufdröselst, hast du weiterhin eine schlanke code behind und die logik getrennt von der View. Man könnte meinen das die Code Behind die ViewModel ist.

Ich hab zufällig
> gesehen und da finde ich deinen "Sinnenswandel" interessant.
Vor allem genau das was ich hier auch erwähnt habe:

ich kann mir nur vor stellen das die logic in der behind steckt und ui in der xaml
das ist aber keine trennung
Du wirst sicherlich die Gründe dafür haben - darauf müssen wir nicht eingehen.

Ich war zu beginn sehr Fanatisch, das ist korrekt, nach einer weite merkte ich aber das ich im Prinzip nur noch für dem MVVM entwickelt habe, das mein Focus völlig falsch war, ich dachte nie "Wie löse ich das Problem" sondern "Wie löse ich das problem auf dem MVVM weg"
Ich hatte sehr viel Mehrarbeit, nur weil ich unbedingt immer nach dem MVVM arbeiten wollte.
Bitte nicht falsch verstehen, ich bin kein MVVM Gegner geworden, wenn es angemessen ist entwickel ich auch nach dem MVVM Muster, nur meist brauchte ich die vorteile des MVVM nicht sodass es sich nicht lohnte, wobei die Vorteile mittlerweile schon recht verschwommen sind.

Schade dass ich diesen Beitrag nicht früher gefunden habe denn der
> deckt sich ziemlich mit meiner Einstellung zum Thema.

Ich werde diese Diskussion aber nicht weiterführen denn wenn ich sehe wie du deine Meinung zum Thema geändert hast - wer weiß wie ich das sehen werde wenn ich mehr Erfahrung habe 😉

Man kann sagen das ich meine Meinung geändert habe da ich mal richtig nach gedacht habe das ich überhaupt alles für Aufwand betreibe, und ob sich das alles überhaupt lohnt. Reflektion & Hinterfragen

Es hat sich in der WPF "szene" irgendwie dazu entwickelt das alle gleich rufen man sollte dies und das mit MVVM machen, das liest sich meistens so als wäre MVVM der einzigst gangbare weg (Auch dein Startbeitrag in diesen Thread liest sich so).
Nur bei MVVM ist es genauso wie hier geschrieben wird, nicht pauschal alles mit ein Pattern erschlagen wollen (so wie auch ich das machte) sondern abwägen ob es sinn macht.

Siehe auch winsharps comment in den von dir verlinkten Beitrag:
"Stattdessen kann man IMHO ohne MVVM mit der WPF keine anständige, komplexere Anwendung schreiben"
Das sehe ich ganz und gar nicht so.
Nur weil man die Code Behind verwendet heißt das nicht das man nicht Bindet, das man Controls.Add oder so aufruft...

Und ich hätte direkt mal eine Aufgabe:
Man hat eine TextBox und eine ListView, nach doppelklick auf ein Item wird ein Wert genommen und die Markierung in der TextBox damit ersetzt, der Focus liegt dann auch in der TextBox.

Ich mach das so:

private void ListViewItem_MouseDoubleClick(object sender, MouseButtonEventArgs e)
{
	Placeholder item = ((ListViewItem)sender).Content as Placeholder;
	if (item != null &&
		item.Pattern.Contains("%"))
	{
		int startPos = String_TextBox.SelectionStart;
		string content = String_TextBox.Text;
		content = content.Remove(startPos, String_TextBox.SelectionLength);
		content = content.Insert(startPos, item.Pattern);
		String_TextBox.Text = content;
		String_TextBox.SelectionStart = startPos;
		String_TextBox.SelectionLength = item.Pattern.Length;
		GiveTextBoxFocus();
	}
}

private void GiveTextBoxFocus()
{
	String_TextBox.Dispatcher.BeginInvoke(new Action(delegate
	{
		String_TextBox.Focusable = true;
		String_TextBox.Focus();
		Keyboard.Focus(String_TextBox);
	}),
	DispatcherPriority.Render);
}

Das Ganze Fenster macht sonst nichts, es geht nur um den Zusammenbau eines Strings mit platzhaltern.

Aufruf ist dann einfach

private void OnDo()
{
	FileNameWindow window = new FileNameWindow();
	if (window.ShowDialog() == true)
	{
		string newFileName = window.FileName;
	}
}

Warum sollte ich eine so kleine Klasse mit MVVM aufblähen, (Siehe "MVVM auch in kleinen Dialogen") (Die Klasse hat nur 3 Methoden + Ctor)
und wie würde man das mit MVVM korrekt lösen
zu welchen Vorteil?

Ich frag auch einfach mal so hinein:
Welchen Vorteil Bringt mir das MVVM Pattern allgemein?

Hallo,

eigentlich wollte ich ja nicht mehr antworten, aber das skizzierte Problem ist eindeutig UI (und damit meine ich hier View) Aufgabe und da wäre M* der falsche Weg. Dass das der falsche Weg ist schreibst du selbst, aber die Argumentation dazu passt nicht 😉

Welchen Vorteil Bringt mir das MVVM Pattern allgemein?
Ich würd mal allgemein sagen den gleichen wie dir MVC bringt 😉
Der Unterschied zwischen MVC und MVVM ist ja nicht groß. Wenn du beim MVC das Model anders haben willst wie es vorliegt erstellst du dir eine neue Klasse die das anpasst - die nenn ich mal ViewModel da es das spezialiserte Model für die View ist. D.h. das MVC hat sich geändert zu Model-ViewModel-View-Controler. Beim MVVM wird halt noch der Controler in das ViewModel gesteckt und das wars. Selbige einfache Überlegung gilt auch für MVP.
D.h. aber auch falls das Model 1:1 übernommen werden kann ist das ViewModel im MVVM eben "nur" der Controler von MVC. Daher sind für mich alle M*-Muster fast gleich und es geht ja nicht darum 100% dieses oder jenes umzusetzen sondern um die Ideen dahinter (SoC, Test-, Wartbarkeit, ...).

mfG Gü