ICommand im MVVM

Hallo Community,

Ich beschäftige mich gerade damit eine kleine APP zu Entwickeln.
Leider bringt mich gerade das MVVM im zusammenhang mit ICommand interface an meine Verständnisgrenzen.

Kurzfassung: Ich Programmiere eine Fragen-App, diese beinhaltet ein Loginwindow. Nach dem Login soll dieses Fenster sich schließen und ein neues Fenster soll sich öffnen.
Den Teil habe ich soweit auch schon fertig gestellt ist auch in der jetzigen version funktionsfähig. Nun möchte ich das ganze in den MVVM Pattern schreiben und möchte den Codebehind natürlich wie es sich gehört auslagern in ein model bereich.
Daher - so habe ich es zumindestens nachgelesen, muss ich das ICommand Interface mit Implementieren.

Mein Problem: Ich verstehe den Zusammenhang dieses Interface noch nicht so richtig und vor allem nicht wie genau ich dieses Programmieren muss.

Diese beiden Methoden sind Bestandteile des Interface:
CanExecute(Object) - Definiert die Methode, die bestimmt, ob der Befehl im aktuellen Zustand ausgeführt werden kann.

Execute(Object) - Definiert die Methode, die aufgerufen wird, wenn der Befehl aufgerufen wird.

Dieses Ereignis ist bestandteil.
CanExecuteChanged - Tritt ein, wenn Änderungen auftreten, die sich auf die Ausführung des Befehls auswirken.

Die Frage zu den Methoden wäre nun:
Wie genau muss ich nun die CanExecute(Object) methode definieren, wenn es rein um ein "OK"-Button (der dann Loginnamen + Passwordfield vergleicht) geht?
Wie genau definiere ich die Execute(Object) methode? Muss ich darin dann den Datenabgleich zwischen Name und PW zu den Login daten abgleichen oder wie verhält sich das genau?

Und zu guter letzt, das CanExecuteChange Ereignis - wie genau habe ich dieses Ereignis in dem genannten Kontext zu verstehen oder genauer zu definieren?

Ich weiß das es ziemliche Anfänger Fragen sind undevtl auch etwas dumm rüber kommt. Als hintergrund möchte ich dazu noch erwähnen, das ich Ursprünglich aus einer Anderen Programmiersprache bin und mich auch erst seit ca 2-3 Wochen mit C# auseinander setze, ich lese also auch noch vieles nach, schau mir Videos an usw usw.

Ich wäre dankbar, wenn mir das Funktionsprinzip des Interfaces mit evtl kurze Beispiele jemand mal genauer erklären / erläutern könnte, damit ich die zusammenhänge richtig verstehe.

LG Bene

Hallo und willkommen,

im einfachsten Fall gibt CanExecute immer true zurück (nur wenn es Bedingungen gibt, welche den zugehörigen Button deaktivieren soll, würde man diese dort implementieren) und CanExecuteChanged wird asynchron im Hintergrund immer wieder aufgerufen, um evtl. Bedingungen im CanExecute neu zu überprüfen.
In Execute steht dann der eigentliche Code, welcher bei Aktivierung (z.B. Button-Click) ausgeführt werden soll.

Die übliche Umsetzung der ICommand-Schnittstelle wird mit RelayCommand bezeichnet (welche mittels eines Delegate konfiguriert werden kann), s. z.B.
ICommand Interface In MVVM, Basic MVVM and ICommand Usage Example und Using RelayCommand / ICommand to handle events in WPF and MVVM (ich hoffe, du kannst wenigstens ein bißchen englisch).

danke für die schnelle Antwort, ich werde mich da mal durchlesen 🙂
Englisch ist kein Problem

Guten Morgen zusammen,
vielen dank für die Hinweise von gestern sie haben mich um einiges weiter gebracht.

Aktuell bin ich nun am Login am arbeiten. Aufgebaut ganz simpel erstmal mit Namen (Textbox) und PW (Passwordbox) dazu dann 2 Button einmal "ok" und "Cancel-Button".

Ich habe hier natürlich schon etwas recherchiert und dabei bin ich auf einen Punkt gestoßen der mir immer wieder untergekommen ist - Sicherheitsschwächungen bei der Passwordbox wenn die PasswordHelper-Klasse genutzt wird.
Meine Frage dazu:
Gibt es ein Ansatz, mit dem in dem MVVM Design diese Schwächung vermeiden kann?

2. Frage wäre es da ein Praktikabler ansatz, den Login in einem anderen Pattern / ausgelagert zu schreiben, so das der Login komplett von dem eigentlichen Programm getrennt ist um die schwächung zu umgehen?

Mein erster gedanke war nun, das Login komplett in c# zu Designen mit Datenbank und das eigentliche Programm dann daran angeknüpft im MVVM Pattern zu schreiben - wäre das ein ansatz oder denke ich da in die falsche richtung?

LG Bene

Ich habe hier natürlich schon etwas recherchiert und dabei bin ich auf einen Punkt gestoßen der mir immer wieder untergekommen ist - Sicherheitsschwächungen bei der Passwordbox wenn die PasswordHelper-Klasse genutzt wird.
Meine Frage dazu:
Gibt es ein Ansatz, mit dem in dem MVVM Design diese Schwächung vermeiden kann?

Du meinst, diese PasswordHelper-Klasse?

Ohne zu wissen, an welche Sicherheitsschwächungen Du denkst, nimmst Du damit natürlich in Kauf, dass das Passwort ungeschützt im RAM liegt.
Wenn also jemand weiß, wie Du deine Anwendung aufgebaut hast (im einfachsten Fall hat jemand Source oder Binaries), dann kann diese Person den RAM auslesen und so an das Passwort gelangen.
Ob das ein relevantes Sicherheitsrisiko ist, musst Du oder jemand über dir oder der Kunde entscheiden.

Das Problem kann man aber nicht so einfach umgehen, zumindest nicht, wenn Du irgendwann das Passwort als String brauchst, denn dann liegt es immer irgendwann im RAM.
Du kannst nur versuchen, diese Zeit, in der es im RAM liegt, möglichst kurz zu halten.

Die PasswordBox liefert ja einen SecureString und das kannst Du ganz normal nutzen.
Ich hole mir davon dann das Passwort und verarbeite es weiter, aber eben erst, wenn ich es auch braucht (wenn Login geklickt wird).
Ob das der optimale Weg ist, weiß ich nicht, aber für unseren Fall reicht das aus.

so das der Login komplett von dem eigentlichen Programm getrennt ist um die schwächung zu umgehen?

Und was würde das ändern?
Dann liest man das Passwort eben aus dem RAM des Login-Programms aus.
Wahrscheinlich erhöht das sogar das Risiko, da die allgemeine Komplexität höher ist, was mehr Raum für Fehler bietet.

Vielleicht gibt's Wege, das Problem generell zu umgehen, die kenne ich aber nicht und ich behaupte auch, dass das für die meisten Projekte gar nicht notwendig ist.

Mir ist auch nicht klar, von welcher "Schwächung" Du redest und wie eine externe Anwendung Dir bei einer sicheren Umgebung helfen soll.
Erklär mal Deinen Anwendungsfall, was Du eigentlich tun und sichern willst.

Aber generell:

• Lokale Passwörter speichert man lokal im Windows Credential Manager
• Ansonsten nimmt man externe Dienste dafür

Aber egal in welchem Szenario: Du wirst immer einen Punkt haben, bei denen Credentials (Keys, Passwörter, Tokens) als Klartext im RAM vorliegen.

PS: der SecureString ist schon ewig obsolete und verspricht anhand des Namens falsche Tatsachen.
Siehe dazu auch SecureString Class (System.Security)

We don't recommend that you use the SecureString class for new development. For more information, see
> on GitHub.

Fazit: verwende wenn immer möglich eingebaute Authentifizierungsmechanismen - und nichts eigenes.

PS: bitte [Hinweis] Wie poste ich richtig? beachten und nur ein Thema pro Thread.
Vermeide bitte Endlos-Threads.

Naja um es kurz zu Fassen:
Ich habe von meinem Dozenten die Aufgabe bekommen eine "FragenApp" zu schreiben - Sie soll so aufgebaut werden, das ein Login via Datenbank erfolgt.
Die App selbst soll auch noch eine Jahreslizenz beinhalten (wo ich noch gar keine ahnung habe wie ich dies realisieren kann).
Weiter sagte er das ganze soll in einem MVVM Pattern geschrieben sein und auch die Fragen sollen über eine DB abgerufen werden und über Check Button geprüft werden.
Das Thema Sicherheitsrisiko soll bei der PWBox darin liege, das man den ram auslesen könnte. Wie gravierend das ganze wäre kann ich nicht beurteilen, da ich in der hinsicht null erfahrungen habe.
Für mich selbst ist dies das erste c# WPF projekt, bin quasi in Ausbildung also absolut noch kein Profi - man wächst mit seinen Aufgaben.

Mir ist unklar, worauf Dein Dozent hinaus will (frag ihn?), aber

Das Thema Sicherheitsrisiko soll bei der PWBox darin liege, das man den ram auslesen könnte.

ist kein spezifisches sondern ein allgemeines Sicherheitsproblem. Man kann dies quasi nicht ändern.
Man kann den RAM sogar in flüssigen Sauerstoff oder Trockeneis packen, dann bleiben selbst über Stunden Inhalte im RAM.
Irgendwo gibts eben den Punkt, bei dem eine Ja-Nein-Prüfung erfolgen muss.

Daher speichert man Passwörter auch nicht verschlüsselt, sondern mehrfach gesalzen und gehasht - und man vergleicht die Hashes.
Ändert aber nichts, dass jede Eingabe in der UI-Oberfläche im temporären Speicher laden muss - by design.

PS: das hier hat aber wirklich nichts mehr mit MVVM zutun.