WPF Filtern nach DateTime bzw. Timespan

Genau deshalb hab ich nen normalen ClickHandler verwendet, weil er ja kein MVVM verwendet.
Was meinst du ist schlecht an dem Lehrplan?
Ich finde das man Commands verstehen muss bevor man MVVM angeht, denn sobald man MVVM macht braucht man diese ja schon.

Grüße
Sascha

Nofear23m schrieb:

das man Commands verstehen muss bevor man MVVM angeht,

Hmm?
Commands bauen doch auf MVVM auf - MVVM baut aber nicht auf Commands auf.

oder vlt ist MVVM kein guter Begriff für uns 2 beide, weil ich versteh ja was anneres darunter als du.

Wie dem auch sei: IMO gilt anne Wpf als erstes zu lernen, dass man Klassen coden muss, in denen die Logik abläuft.
Und die Xaml-User-Oberfläche wird ausschliesslich über Bindings mit diesen Klassen verknüpft.
Und auch ein Command ist etwas, was in diesen Logik-Klassen angelegt wird, und ist daraufhin designed, per Xaml-Databinding an die Xaml-Oberfläche gebunden zu werden.

Wie gesagt: der CommandPattern basiert auf Databinding, nicht umgekehrt.

Und ich kann mir nicht vorstellen, dass jmd den CommandPattern versteht, wenner das Wpf-Databinding-Konzept noch nicht verstanden hat.

Aber da sagst du es doch selbst. Wenn man Binding korrekt machen will muss man mit Commands arbeiten. Ja, und da MVVM nur mit Binding funktioniert muss man zuerst mal Commands verstehen sonst kann man erst gar kein MVVM machen. Also verstehe ich dich jetzt nicht ganz. Oder wir reden aneinander vorbei.

MVVM geht ohne Commands nicht. Also muss man zuerst Commands lernen. Somit wprde mein Lehrplan also stimmen. Ich habe im Übrigen drei Bücher hier wo dies genauso gemacht wurde. Ich hatte mich zwar nicht daran Orientiert, aber gerade nochmal nachgesehen.

Ob wir unter MVVM das gleiche verstehen oder nicht (eigendlich lässte es gar keinen Spielraum zu aber egal) ist ja nebensache, das Pattern geht nicht ohne Commands zu verwenden. Also muss man wissen wie diese Funktionieren.

Grüße
Sascha

Nofear23m schrieb:

MVVM geht ohne Commands nicht.

Dem widerspreche ich.
Commands sind "nur" das Wpf-Konstrukt, um Button/Menu-Klickse ins Viewmodel zu transportieren.
Ja klar, kaum eine Anwendung kann ohne Buttons oder Menus auskommen.
Aber manchmal geht das auch ganz gut.
Grad in diesem Beispiel, für die Filter-Thematik, braucht man keine Buttons, sondern Checkboxen sollte anzeigen, ob ein Filter aktiv ist oder nicht (und ihn auch aktivieren/deaktivieren) (so eine ist in meim Sample auch drin).
Button/Menu braucht das Sample (noch) nicht.

Also Buttons sind wichtig, und daher ist der CommandPattern wichtig.
Aber CommandPattern ist nicht die Vorraussetzung von MVVM, sondern umgekehrt.

Von daher bleib ich bei meiner Ansicht, dass der TE sich erst mit dem allgemeinem Binden an ein ViewModel auseinandersetzen sollte (MVVM), bevor er (darauf aufbauend) die spezielleren Command-Bindings anfasst.

Gut, da brauch ich nicht weiter zu schreiben. Wiedermal ist bei dir Binding an eine Klasse mit MVVM gleich gesetzt. Was siehst du ein das es ein Pattern ist, bitte tu dir selbst einen gefallen und lese die definition von MVVM durch.

Und nur so nebenbei macht der TE kein MVVM also ist klar das das Sample es nicht braucht. Hatte ich ja auch nicht drinnen, nur so zur erinnerung.

Ich sags nochmal, überlege dir für "dein Pattern" einen Namen. MVVM ist es nicht. Es ist nur Binding an Klassen, was bei Gott nicht gleich das selbe ist.

So, das wars für mich hier, das gehört nicht in den Thread.

PS: Bei deiner erklärung was ein Command überhaupt ist glaube ich fast du hast Commands nicht ganz verstanden, könnte aber auch falsch rüber gekommen sein. Nur ein Konstrukt für Klickse ist geil.

Tut mir leid, dass ich dir widerspreche, wenn du mal falsch liegst.

Nofear23m schrieb:

MVVM geht ohne Commands nicht. Also muss man zuerst Commands lernen.

ist einfach Quatsch, und stellt die logische Abhängigkeit der Konzepte auf den Kopf.

Da unterstell mir bitte nicht (oder stelle diesbezügliche Vermutungen auf), ich hätte iwas nicht verstanden.
Das gehört nämlich sicher nicht in diesen Thread, diese Vermutungen zu entkräften oder zu bestätigen.