Moin,

dies ist mein erster Post hier Gruße an die Community und Danke für's aufnehmen und ich hoffe doch im richtigen Bereich zu sein.

Ich habe ein projekt in welchem ich (absichtlich und im vollbesitz meiner geistigen Kräfte) CodeBehind verwende
UND gerne INotifyPropertyChanged Mechaniken nutzen möchte. Leider ist die Sache mit "etwas" Tricky.

Ich habe ein Window mit mehreren Fields und bin in MVVM noch nicht sicher würde aber gerne die Vorteile Nutzen.

Gibt es Design Patterns hierfür?

Danke

Ähm. MVVM ist bereits das Design Pattern und INotifyPropertyChanged ein hilfreiches Implementierungsdetail dazu.

Ich kann nur vermuten das dir ein vernünftiges Beispiel fehlt?
Hier wäre eins www.c-sharpcorner.co...tychanged-interface/

Das zeigt zumindest eine Standardimplementierung. Falls du mit "Tricky" was spezielleres meinst solltest du genauer darauf eingehen.

Du kannst im CodeBehind die DataBinding-Vorteile nutzen, indem Du INotifyPropertyChanged im CodeBehind implementierst und den DataContext auf this setzt.
Allerdings ist dein Control dann einfach nur Control und ViewModel in Einem, Du hast also weiterhin MVVM, nur in verkrüppelt
Da ist nichts tricky, es ist nur unsauber - oder Du meinst etwas anderes?

Wenn Du im CodeBehind auf Property-Änderungen vom DataContext (ViewModel) reagieren willst, ja, dann ist es tricky
In dem Fall bleibt dir nur, das PropertyChanged-Event zu abonnieren und darauf zu reagieren. Und wenn es mehrere Properties nacheinander sind ... mein Beileid
Oder Du machst es nicht im CodeBehind, dann hast Du das Problem nicht.

CodeBehind ist nicht automatisch falsch, es ist nur dann falsch, wenn es ins ViewModel gehört - leichter gesagt, als getan.

Ich persönlich schreibe nur ganz selten was ins CodeBehind.
Meistens arbeite ich mit Bindings und Triggern (das ViewModel kann die Grundlage liefern) oder Behaviors.
Wenn das auch nicht geht, ist ggf. ein CustomControl eine gute Idee, gerade für mehrfach genutzte und komplexere Controls oder wenn man ein eigenes Template braucht, ist das das Mittel der Wahl.
In den Fällen, wo das alles nicht geht und die Logik wirklich ausschließlich WPF spezifische UI-Logik ist und konkreten Control-Zugang benötigt, dann kommt es in den CodeBehind und dann ist es auch in Ordnung.
Manche schreiben auch im CodeBehind, wenn eine saubere Lösung zu aufwändig wäre, aber damit sollte man immer vorsichtig sein, solche "Lösungen" neigen dazu, auf Füße zu fallen


Je nachdem, was Du vor hast, bringt das der CodeBehind auch Nachteile mit sich, wie z.B. dass es ziemlich nervig ist, auf sich ändernde ViewModel-Properties zu reagieren.

Palladin007 hat folgendes geschrieben :

... MVVM, nur in verkrüppelt ... es ist nur unsauber - oder Du meinst etwas anderes? ... wenn es mehrere Properties nacheinander sind ... mein Beileid

Ja, Ja und ja...
...ja, ist gut - ich gebe diesen Plan auf.

Ich mag MVVM, und habe schin etwas Erfahrung darin.
Mein Problem ist SQL in MVVM und das Handling mit mehreren Seiten.

SQL habe ich bisher in Klasse gemacht und instanziiert, dann meinte mal einer das wäre unsauber hat aber nicht gesagt wie ich es sonst machen soll.

Ich habe ein Projekt mit vielen Feldern und komplexer Mechanik und SQL und wollte es ich noch nicht in MVVM machen, aber schauen ob ich manche der Vorteile nutzen könnte.
Man muss bei vielen Feldern, deren Events und so auch alles Einzeln machen und kann es nicht chillig "einfach in das Objekt(der Klasse) schreíben und gut is...".

SQL und MVVM? Sorry, aber das beides könnte kaum weiter von einander entfernt sein.
MVVM ist ein reines UI-Pattern, drum herum wird meist zusätzlich noch eine Multitier architecture verwendet.
MVVM ist kein DataBinding, MVVM ist ein Design-Pattern, das mit DataBinding seine vielen Vorteile ausspielen kann.

Zitat:

SQL habe ich bisher in Klasse gemacht und instanziiert

Wie meinen?
SQL gehört, egal ob mit MVVM oder ohne, ins Data-Layer oder je nach Architektur-Modell woanders hin.
Also ja, scheinbar hat die unbekannte Person recht und es ist unsauber, aber deine Schlussfolgerung vermutlich noch unsauberer

Da muß ich Palladin007 zustimmen.

MVVM ist ein Modelsystem das für die UI gedacht ist um UI Probleme zu lösen.
SQL ist was das du in einem Model für die Persistenz brauchen kannst um Datenablage/Abfrage Probleme zulösen.

Eine halbwegs saubere Architektur trennt diese Aspekte und mappt dann dazwischen.

Zu meiner Verteidigung, ich habe die Ausbildung zum Anwendungsentwickler erst vor ein paar Monaten abgeschlossen und bin eigentlich zu alt für vieles.

Und MVVM beherrsche ich auch erst seit kurzem. Also wenn es, so wie ich es bisher gemacht habe, nicht gemacht wird, wüsste ich nicht wie ich es anders machen sollte,
da ich die SQL Methoden ja nicht in die CodeBehind Datei schreiben kann.

"... trennt diese Aspekte und mappt dann dazwischen" wüsste ich nicht wie...
"SQL gehört, egal ob mit MVVM oder ohne, ins Data-Layer" das mit den Layern hat mir auch keiner richtig beigebracht...

Aber das wäre sowieso ein eigenes Thema.

Trotzdem Danke

Moderiert von Th69: Beitragsformatierung überarbeitet.

Hallo und ,

da sollte dir [Artikel] Drei-Schichten-Architektur (wenn auch aus anderem Forum) weiterhelfen.


PS: @Ralf, was du meinen mit erstem "Satz"?

@TH69 das wüsst ich auch gern

Zitat:

Zu meiner Verteidigung,

Es gibt keinen Grund sich hier verteidigen zum müßen. Du fragst wir beraten du entscheidest.
Und du hattest doch nach "Design Patterns" gefragt Das erwähnte Aufteilen in Schichten/Layer ist eins. Sogar ein sehr empfehlenswerters.

Zitat:

Ich habe ein Projekt mit vielen Feldern und komplexer Mechanik und SQL und wollte es ich noch nicht in MVVM machen

Und genau da hilft die Strukturierung in verschiedene Schichten/Layer. Das was du als komplexe Mechanik beschreibst hat sicherlich mit den Fragen zu tun "wie zeige ich es an", "wie lege ich es ab", "wie verarbeite/verändere ich Daten". Eigentlich sind es drei Probleme und wenn man die auf z.B. drei Schichten verteilt hat man drei kleinere Probleme die dann üblicherweise auch einfacher zu lösen sind als wenn man nur auf denn einen großen "komplexe Mechanik"-Haufen schaut und glaubt überfordert zu sein. Ds vorgehen Ist ein geflügtes Wort in der IT (Divide et impera, Teile und herrsche, divide and conquer oder in welcher Sprache man das auch immer gerade ausdrücken will)

Ich lasse erstmal die Finger von MVVM.

Die Umsetzung/Realisierung in die 3 Schichten ist ne feine Sache und vom Prinzip und Sinn habe ich es verstanden.
Nur weiß ich nicht wie ich es praktisch umsetzen kann.

Gerade in einem Projekt wo eine Anbindung an MariaDB z.B. erforderlich ist und wo z.B. die Logikschicht auf die Präsentationsschicht zugreifen muss (Button.IsEnable=false)...
Ist das ein Zugriff? Verboten? Wenn ja, wie dann?

Derartige Details und andere Pipapöchen gehen aus dem Artikel nicht hervor und waren auch nicht Bestandteil der Ausbildung...

Moderiert von Th69: C#-Tags hinzugefügt

Die Logikschicht sollte niemals (direkt) auf die UI-Schicht zugreifen (sie sollte quasi selbständig lauffähig sein).
Übergebe alle benötigten Werte als Eigenschaften an die Logikklassen (bzw. -methoden) bzw. erfrage sie (z.B. mittels Ereignissen).
Eine fortgeschrittenere Möglichkeit ist per Schnittstelle (interface), als Stichwort dazu: "Dependency Injection (DI)" bzw. generell "Inversion of Control (IoC)".

Ich kann dir noch meinen Artikel Kommunikation von 2 Forms empfehlen (wenn auch primär für WinForms geschrieben, ist jedoch genauso für WPF anwendbar, insb. ohne MVVM - auch wenn man eigentlich zwingend MVVM bei WPF benutzen sollte).

Tja, leider werden Architektur und Design (- Patterns) in einer Ausbildung häufig nicht detailliert genug gelehrt, sondern meistens nur am Rande angesprochen.