WPF - Notizbuch, 2-3 User,

Hey,
Ich Versuche mich seit ein paar Tagen an einer kleinen App (Adressbuch) zum üben und verstehen.
Möchte es gleich in mvvm machen damit ich hinterher nicht nochmal umlernen muss, auch wenn es sich für so ein kleines Projekt nicht lohnt. Ich möchte damit lernen.

Habe mir dazu 3 weitere Projekte in dem Hauptprojekt angelegt. Model, View, Viewmodel. Diese 3 sind als WPF Klassenbibliothek deklariert.
Im Model habe ich eine Klasse namens Person angelegt, welche Eigenschaften wie Vorname, Nachname etc. Hat.
Das View habe ich bereits in mehreren Usercontrols erstellt.
Und nun hänge ich an dem Verständnis des Viewmodels.
Hier hast du in deinen zahlreichen Beispielen immer ViewModelKlassen und Workspace genutzt. Alles beinhaltet wiederum Klassen mit Eigenschaften und mehr.
Da verstehe ich nicht was die viewmodelklasse darstellt und was der Workspace.
Vielleicht verwirrt es mich auch weil es wieder Klassen mit Eigenschaften sind.

Kann mir das jemand genauer erläutern?

Hallo Akanel

Akanel schrieb:

Ich möchte damit lernen.

Super

Akanel schrieb:

Diese 3 sind als WPF Klassenbibliothek deklariert.

OK, jetzt kein direkter Fehler, aber hier sind denn unnötige verweise mit dabei. View = WPF Klassenbibliothek, Model = Normale Klassenbibliothek, ViewModel = Normale Klassenbibliothek

Akanel schrieb:

Da verstehe ich nicht was die viewmodelklasse darstellt und was der Workspace.
Vielleicht verwirrt es mich auch weil es wieder Klassen mit Eigenschaften sind.

Im Grunde ist ein Workspace nichts anderes als ein ViewModel nur benamse ich es gerne anders wenn ein ViewModel mehrere Views zusammenfasst und nenne dies dann gerne Workspace.
Die Faustregel ist: Für jeden View ein ViewModel. Das ViewModel stellt alles bereit was ein View anzeigt.

Habe ich aber das Hauptfenster habe ich hier viele Views (oder Teilebereiche) wie z.b. die Menüleiste, ein oder mehrere Hauptteile in der Mitte, eine Statusbar und vieleicht noch irgendwo ein weiteres Menü oder sowas.
Jeder dieser Teilbereiche ist ja ein View für sich und hat also auch ein eigenes ViewModel (StatusBarViewModel, MenuBarViewModel, MainViewModel usw.)
Diese fasse ich zusammen zu einem MainWorkspace welcher die jeweiligen ViewModels als Properties beinhaltet.

Ich hoffe ich habe es halbwegs erklären können. Wenn nicht kann ich gerne "nachbessern" mit ner Zeichnung und nem Diagram.

Grüße
Sascha

Da ich noch auf Arbeit bin und gerade kein Visual Studio zur Hand habe, fasse ich mal kurz zusammen wie ich es verstanden habe.

Pro View ( zb. uclStatusBar) benötigt man ein ViewModel ( zb. StatusBarVm)
Du selbst unterteilt das ViewModel aber nochmal in die VieModelKlasse und den Workspace.
Die Viewmodelklasse enthält demnach die Properties etc. Und die eigentliche Logik ist dann in dem Workspace.
Rein theoretisch könnte aber auch alles in eine Datei. Dient halt der besseren Übersicht und Wartbarkeit, wenn man es verstanden hat.

Wenn das soweit richtig ist, hören endlich die Kopfschmerzen auf.
Dann hätte ich noch eine Frage, aber dazu erst wenn ich hier richtig lag.
Vielen Dank für deine Mühe, Geduld und ausführliche Antwort.

LG Sven

Akanel schrieb:

Du selbst unterteilt das ViewModel aber nochmal in die VieModelKlasse und den Workspace.
Die Viewmodelklasse enthält demnach die Properties etc. Und die eigentliche Logik ist dann in dem Workspace.

Ne, alles ist dort wo es benötigt wird. Ich habe ja geschrieben das ein Workspace im Grunde auch eine normale ViewModel-klasse ist. Nur nenne ich diese einfach Workspace. Das kann jeder so machen wie er will.

Sicher kann alles in eine Klasse. Es kann auch die ganze App in eine Klasse, die Übersicht leidet aber darunter.

Ob du jetzt für jedes UserControl ein viewModel machst oder nicht bleibt dir überlassen und kommt immer darauf an.
Du darfst dich jetzt nicht darauf verbeissen. Es gibt hier nix fixes. So in der Art ucl = View = ViewModel

MVVM ist ein Pattern, da gibt es nur relativ wenig falsch oder richtig. Es ist ein Rezept. Ein Rezept kann man verfeinern nach beleieben oder mal auch eine Zutat weglassen ohne das plötzlich was ungenießbares rauskommt.

Ich mach es immer so das ich mir mein Fenster vorstelle. Mach die Augen zu und stelle dir vor was du haben willst, wenn du da was du machen willst direkt in mehrere Teilbereich unterteilen würdest weist du das du mehrere ViewModels brauchen wirst.

Grüße
Sascha

Hi,
mir geht es ähnlich wie dir. Eventuell bin ich paar schritte weiter. Aber Grundsätzlich ist es bei Listbox und Textboxen recht einfach. Du hast eine List of irgendwas oder besser eine ObservableColkection. Diese bindest du an die Listbox. Über einen Button (dieser wir an einen Icommand gebunden) fügst du dann die Einträge aus den 3 Textboxen der Liste hinzu.

Mhh naja, ich bin jetzt auch leider wieder ein paar Tage raus. Aber ich glaub schon etwas von den Grundlagen verstanden zu haben.
Nimm einfach mal nur das UserControl uclHeader.xaml. Hier findest Du die Zeile: d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True,Type={x:Type workspace:HeaderWorkspace}}".
Diese gibt dir schon mal den Hinweis, an welchen Workspace es gebunden ist.
So findest Du auch unter dem Verzeichnis Workspace den HeaderWorkspace. Hier kannst Du einerseits sehr gut die in der XAML gebundenen Commands (As ICommand) finden.
Auch den Text des ersten Button wurde hier angebunden, während die anderen beiden Buttons fest zugewiesenen Text aufweisen. Also etwas suchen und man kommt schon voran. Am Anfang musste ich mich nur so durchhangeln. Mit der Zeit und Übung bekommt man erst den Blick dafür, erinnert mich daran wie ich als Kind gelernt hatte Pilze im Wald zu finden....

Hallo @asusdk

Ich verstehe dich. Und ohne dich entmutigen zu wollen muss ich dir sagen das Vererbung, das verständnis für Interfaces und der gleichen schon sitzen sollten. Sonst wirds eng und du wirst den Code nicht nachvollziehen können.
Was Commands und RelayCommands sind gibt es sooo viel im Netz. In der WPF geht so gut wie alles über Commands. Ein Command kann nämlich gebunden werden da es als Property erstellt werden kann.

Lese dir im Netz ein wenig durch. Wie genau die Commands im Detail funktionieren ist nicht sooo wichtig.

Dann bleibt noch zu sagen das es wichtig ist zu verstehen das wenn man mit Binding arbeitet es immer eine Klasse geben soll/muss welche den View abbildet.
Willst du z.b. einen Text in eine Textbox haben brauchst du ein Property in der Klasse (welche an das View begunden ist) vom Typ String. Willst du eine Checkbox binden dann ein Property vom Typ Boolean. usw.

Alles was du in einem View siehst muss es im ViewModel geben. In Form von Eigenschaften (Properties). Und bei einem Button wird die Command Eigenschaft an einen Command gebunden.
An was für einen Commadn bleibt dem Programmieren überlassen. In meinen Beispielen fast immer ein RelayCommand. Wie die Klasse heisst ist egal, wichtig nur sie Implementiert die ICommand Schnittstelle da dies nötig ist um die Command Eigenschaft eines UIElements zu Binden. Und hier sind wir nun wieder bei den Interfaces. Da ist es wieder wichtig zu wissen wie Interfaces funktionieren. Aber das findet man in jedem Buch, auch in den kostenlosen.

Aber gerne kannst du dir eine Klasse oder einen View aus dem Notizbuch raussuchen und wir gehen die Funktionsweise durch. Aber meine Vorredner können dir da auch bereits gut Helfen, die sind da eh schon ganz fit.

Grüße und gute N8
Sascha

asusdk schrieb:

also wenn das die Früchte sind die man nun dank OOP-Wahn erntet.... wirkt so als wolle man nur noch studierte in dem Gebiet haben, ja allen Hobbyprogrammierern alles nur immer unnötig schwerer machen....

Bitte vergiss nicht das dies bereits sehr nah am MVVM ist. Das darfst du nicht vergessen.

WPF geht auch mit EventHandler und CodeBehind. DU willst aber mit Binding arbeiten und die stärken der WPF verwenden. Dann muss man sowas aber auch erlernen.
Und neu ist das nicht, das bin ich in den Tutorialvideos beim Thema Binding durchgegangen. Wenn in einem Video was unklar ist/war kannst du gerne genauer Nachfragen.

Glaub mir, es wirkt nur kompliziert, das ist es aber gar nicht. Du definierst dir ja nur Bausteine welche dann zusammengebaut werden. Mehr ist es im Grunde nicht.

Grüße

asusdk schrieb:

Aber derartig selbsterklärendes scheint in MVVM/WPF nicht mehr vorhanden zu sein, daher ist es mir Quasi nicht möglich einen zusammenhang in diesem Code-Meer zu finden....

Mmmhhhh

Also in ViewModel ein Command wie:

Ist doch wirklich aussagekräftig genug oder?
Im XAML ein:
sagt glaube ich auch mehr als stark genug aus das der Button speichert oder?

Es ist anders, richtig. Aber deshalb nicht schlechter oder umständlicher.

asusdk schrieb:

Das ganze dann wesentlich erschwert dadurch, dass sich das ganze noch auf 13 Klassen aufteilt

Kommt auf den Betrachtungswinkel an. Was wird wohl leichter zu warten sein? Mmmmhhh. Etwas was brav aufgeteilt ist in die jeweilige Klasse und in der Klasse habe ich die Funktionalität drinnen die genau dieses Objekt betrifft oder der meiner Meinung nach Spagetticode eine WinForms. (Ich meine damit ein WinForms die in keinerlei Klassen aufgeteilt ist, sonst würde ja auch dort genau das selbe rauskommen, hat also eh weniger mit der WPF zu tun)

Außerdem weis ich gar nicht wie oft ich gesagt habe das MVVM erst bei größeren Projekten sinn macht, aber hier anhand eines kleinen Beispiels die funktionsweise übersichtlich dargestellt wurde. In großen Projekten ist MVVM übersichtlicher, glaub mir.

Aber du hast schon recht, ohne die Grundlagen der Objektorientierten PRogrammierung macht MVVM so gar keinen Sinn zu erlernen. WPF wie WinForms zu verwenden ja, MVVM aber nicht.
Das bringt nix. Du brauchst die Grundlagen der OOP, und die sollten sitzen. Bei Fragen kannst du gerne nachfragen, aber das hast du nicht. Du sagst du hast sooo lange den Code studiert, aber du hast nie etwas gefragt, warum?
Das die flinte ins Korn werfen und sagen das ist alles viel zu kompliziert ist ein logischer schluss der verständlich ist.

Ich habe auch ne weile gebraucht um es zu verstehen (hatte aber leider niemanden den ich fragen hätte können).

Grüße
Sascha

@asusdk So ging mir das auch, Jahr für Jahr habe ich vergeblich versucht mich WPF anzunähern. Was ich schreibe ist nicht wissenschaftlich und wirklich nur meine sehr persönliche Meinung.
Seit ich mich auf @Nofear23m Tutorial mal völlig unbeleckt und ohne ein definiertes Ziel vor Augen angenähert habe, konnte ich überhaupt erst die Kurve kriegen.
Für Leute, die mal eben schnell funktionierenden Code schreiben wollen, und auch gerne dazu alles was hier als Grundlagen gelten, über Bord werfen, ist WPF nichts.
Für jemanden, der wie Du gerade (und ich in den vergangenen Jahren auch immer) den direkten Vergleich zu WinForm sucht, ist WPF, sehr, sehr schwer zu lernen.
Erst wenn man bereit ist, wirklich alles was man glaubt zu wissen, hinter sich zu lassen, geht es. Für diejenigen, die Winform noch gar nicht kennen, ist das vielleicht auch gar nicht so schwer.
WPF, vor allem MVVM Konform, geht eben nicht direkt und GUI Unterstützt. Wo man per Doppelklick auf einen Button von der GUI unterstützt ein Event abboniert, gibt es in WPF nach MVVM Pattern nicht.
Ja es ist deutlich komplexer, hat deutlich mehr "Schichten". Der Vorteil, man kann alles machen, es gibt nichts was nicht geht, vorausgesetzt man findet den Weg. Ach und es gibt auch fast immer zig Wege, die alle richtig sein können. Der Vorteil von Winform ist eben, man hat schnell ein Progrämmchen geschrieben.
Aber sieh Dir doch nur die meisten "Probleme" die im Forum gepostet werden an. GUI von Daten trennen? Fehlanzeige.
Naja, ich bin selbst noch blutiger Anfänger, aber nach meinem ersten Erfolg kommt auch das Verständnis, und wenn man Blut geleckt hat.... WPF ist saugeil^^

Dksksm schrieb:

GUI von Daten trennen? Fehlanzeige.

Richtig, und das ging mir unter WinForms immer auf den Keks. Ich will zum einen die Kontrolle haben wie ich wann welche Daten wo Abrufe (deshalb ging mit das gante DataTable, DataSet und Dinges irgendwie auf den Keks) und die View soll unabhängig davon arbeiten.

Dksksm schrieb:

und wenn man Blut geleckt hat.... WPF ist saugeil

Ist witzig, jeder der die Kurve krigt sagt das.

Aber so nebenbei. Ich kann unter WPF genauso "mal schnell ein progrämmchen schreiben". Denn ich kanns ja genauso verwenden wie WinForms. Warum denn nicht?
Es spricht nichts dagegen. Zumindest nicht wenn ich nicht mehr UI benötigt. Denn DataTemplate und das ganze gibts dann hald nicht.
Aber.... wenn ich so wie in WinForms arbeite kann ich ja trotzdem schnell mal ne Klasse und ein DataTemplate reinkloppen und per CodeBehind die Listbox darauf binden und zack habe ich ein super UI ohne MVVM. Warum nicht?

Aber die Frage ist ob du dir das Programm dann in ein paar Jahren ansehen willst.
Sein wir uns ehrlich. Größere WinForms Projekte haben auch SEHR VIELE Klassen. Da es sich einfach so gehört wenn man sauber Programmieren möchte. Die paar ViewModel die unter WPF dazu kommen sind jetzt auch nicht mehr so tragisch. Ich hatte mal ein WinForms Projekt mit ca. 300 Klassen. Und? In Namespaces und Solutionfolder aufgeteilt ist das nicht der Rede wert.

Grüße
Sascha

Tu dir bitte keinen zwang an Fragen zu stellen. Danke daran. Es gibt keine blöden Fragen, nur dumme Antworten. Verstehst du den zusammenhang zwischen zwei Klassen oder eine Klasse und einem View nicht, oder Teile einer Klasse nicht Frag einfach. Verstehst du ein Schlüsselwort nicht dann Frag. Egal was.

Am besten du betrachtest das Projekt von der ferne. Also erstmal nicht im Detail sondern erstmal ansich wie ein View mit einer Klasse verbunden ist. Dann das Binding dazu. Erst wenn du das verstehst kannst du dich an die Details einer Klasse machen.

Grüße
Sascha

Hallo

asusdk schrieb:

bislang ist muss ich leider zugeben das einzig für mich wahrlich interessante, dass mit den Templates ist, gibt es diese ausschließlich in der WPF, oder kann man vergleichbares auch in Winforms erreichen ?

Na da bist du ja noch nicht weit genug. Interessant wirds ja erst. Wennste mal das Inhaltsverzeichnis ansiehst, wirst du merken das da noch so einiges kommt.
Unter WinForms ist dies nicht möglich, da musst du immer ein neues Control erstellen. Das ist unter WPF eben super Easy, und zwar kannst du JEDES Control anpassen.

asusdk schrieb:

finde ich fast gleichzusetzen wie, direkt eine neue Sprache lernen

Nicht wirklich. Der Unterschied ist ja im Grunde das dich die WPF zur Objektorientierten Programmierung zwingt. Was man ja unter WinForms auch machen sollte aber da es einem nicht aufgezwungen wird ziehen es die wenigsten durch, schon gar nicht die "Anfänger". Anders ist im Grunde nur Binding und XAML als Designersprache. Und XAML ist nun echt nicht schwer. Alles andere bleibt VB Code wie es ist und war. Da ist rein gar nichts anders.

asusdk schrieb:

nicht besonders Vorteilhaft gegenüber "normalem" VB-Code (welcher einfacher zu lesen ist, und wenigstens eine vollständige Intellisense bietet)

Es ist normaler VB Code. Was denn sonst? Siehst du wo anderen Code. Ja, von Design, aber das wars schon. Und Intellisense hast du mit WPF genauso. Vorausgesetzt man macht es richtig. Denn auch für Binding und der gleichen hat man Intellisense wenn man es richtig macht. Und nicht nur das. Man kann seine Views sogar zur Designzeit mit Beispieldaten füllen lassen um direkt zu sehen was man da im View macht. Und noch besser. Während das Programm läuft (im Debbuggin) kann ich sogar den XAML ändern und sehe die änderungen direkt im laufenden Programm. Das zeig doch mal unter WinForms bitte.

asusdk schrieb:

kann mir hier jemand klar darlegen/erläutern was genau daran der Vorteil ist/sein soll ? Also gegenüber dem guten alten Forms ?

Sicher, ob das nur so viel sinn hat weis ich nicht. Das Problem ist das du gerade mit Lego Technik herumprobierst und willst aber morgen zum Mond fliegen. Das ist nicht Böse gemeint!!
Du kannst nicht von 0 auf 100 in einem Tag. Das klappt nicht.
Wenn du sagst das du das nicht verstehst und dir noch ein paar Grundlagen fehlen ist das in Ordnung, gar nicht verwerflich daran. Wenn du sagst du willst was neues lernen dann mach das auch. Gehe Kapitel für Kapitel durch (auch die wo du meinst das brauchst du nicht - glaub mir, es gibt zusammenhänge) und lerne das gezeigte. Wir kommen bestimmt noch zu dem Punkt wo du die WPF das verstehst und dann wirst du dastehen und sagen - "achso, jetzt hab ichs, das ist ja gar nicht so schlimm. Es logisch aufgebaut."

Der größte Vorteil ist erstmal neben dem ganzen Grafischen zeugs und der anpassbarkeit der ganzen Controls (wie du ja bereits gemerkt hat) ein ganz anderer. Das Binding!!!

Binding ermöglicht es erst das die View vom Code getrennt ist. Jetzt wirst du sagen: "ja und, was bringt mir das". Sehr viel. Jetzt direkt vieleicht nicht gleich, aber später sehr, sehr viel. Dazu musst du aber ein wenig die Zusammenhänge verstehen. Du kannst deinen Code unabhängig vom View erstellen. Bist nicht auf Controls oder Controlsnamen gebunden. Du kannst jederzeit die Optik und die Benutzerführung ändern und alles umbauen ohne nur eine zeile VB-Code ändern zu müssen. Weiters hat diese Trennung den Vorteil das dein Code Testbar wird. Und zwar durch UnitTests. Das wirst du noch nicht brauchen, aber es wird dadurch möglich. Ich könnte noch so viele Punkte aufzählen aber ich denke ich sollte nicht ZU viel schreiben denn wenn du direkt auf dem Mond fliegen willst, wirst bu bestimmt nicht sehr hoch fliegen bis es wieder abwärts geht. das habe ich schon oft erlebt. In diesem Fall kann ich dir nur nahe legen das du vieleicht bei WinForms bleibst. Zumindest so lange bis du bereit bist die Zeit und die Geduld für etwas neues aufzubringen.
Wenn ich 10 Jahre als Mechaniker auf Autos gearbeitet habe, werde ich sicher nicht morgen auf die schnelle lernen ein Boing Triebwerk zu reparieren, ich bin sicher das fliegt mir um die Ohren.

Die WPF ist sehr leistungsstark und eröffnet neue Möglichkeiten, aber man muss umdenken. Es ist nicht so schwer wie man Anfangs glaubt (ich weis, Anfangs fühlt man sich erschlagen) aber man muss eben umlernen.
Wenn es so mir nichts, dir nichts ginge bräuchte ich keine Tutorialreihe machen oder? Nein? Doch? Wie? OK, Faden verloren.

So, das wars dann. Du sehst nun an einer Kreuzung würde ich sagen. Du wählst wo du lang gehst.

Grüße
Sascha

Ich komme um eine Anmerkung nicht herum, doch es ist sehr, sehr schwer. Nämlich dann, wenn man a) kein Profi ist und b) sein "Wissen" überwiegend aus dem Internet zusammengesaugt hat. Gerade als VB'ler hat man es dann sauerschwer, weil der Code ist eher VB6 Code als OO (VB.Net), sieht man hier im Forum auch immerzu. Der Grund für mich vor Jahren bereits VB.Net den Rücken zu kehren und nur noch C# zu programmieren, ist vor allem genau diesem Umstand zu verdanken. Ein Gelegenheitsprogrammierer überschätzt sich schnell, wenn die Kenntnisse auf YouTube Videos und solchen "quick and dirty" code basieren.
Da gibts auch kein Model, kein ViewModel, sondern eigentlich nur eine Mantsche, die sich aus dem "GUI-Controll"-Ereignissen und den Code darin ergibt.
Deshalb, ist nur meine Meinung, ist es für viele hier sehr, sehr schwer WPF zu verstehen. Ich schliesse mich gerne ein wenn ich sage, wir müssen erst mal OO programmieren lernen. Das sieht dann immer noch wie VB oder C# aus, hat aber wenig mit dem zu tun, was wir vorher verbrochen haben.

Grüße
Rob