Support, Anregungen, Wünsche zur Tutorialreihe <WPF lernen/>

  • WPF MVVM

Es gibt 448 Antworten in diesem Thema. Der letzte Beitrag () ist von Nofear23m.

    Hallo Leute

    Die beiden neuen Beiträge wurden nun Freigeschaltet.
    Hier der Permalink: Tutorialreihe <WPF lernen/>

    Viel spass damit, ich hoffe man kann was dabei lernen!!

    PS: Freue mich wie immer über Kommentare und/oder Likes und Kritik!!

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    So Leute,

    es geht direkt weiter mit dem nächsten Kapitel. Im letzten Video hatte ich es ja bereits angeschnitten wobei ich es im aktuellsten Beitrag genau erkläre und auch in einem Video anhand von Beispielen erklähre.
    Designtime-Support

    Für mich nicht mehr weg zu denken. Ich erstelle keinen View mehr ohne das ich DesignTime-Support habe, meiner meinung nach ist das Fehlen des Designtime Datenkontexts der Grund warum sehr viele nicht in WPF Designen wollen und sofort wieder zu WinForms zurück gehen. Denn ohne machts keinen Spaß!!

    Hier gehts zum Beitrag

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hallo

    Ansich habe ich es wie man im Inhaltsverzeichnis sehen kann eigendlich nicht vor.
    Das hat den einfachen Grund das Datasets meiner Meinung nach heute nicht mehr benötigt werden, zumindest nicht in der WPF. Datasets und alles was damit einhergeht wird in der WPF nur kompliziert. Man kann auch dieses ganze Zeugs wie Tableadapter und co nicht einfach mit dem Designer auf ein Form ziehen. In der WPF bindet man fast immer eine CollectionviewSource auf Controls wie z.b. DataGrids.

    Ich hatte in der WPF noch nie den drang ein DataSet zu verwenden und habe es auch noch nie gemacht, kann aber gerne in einem Video darauf eingehen wie man es machen würde wenn man es denn will.
    Wie man dem Inhaltsverzeichnis entnehmen kann wollen wir ja zu MVVM und Testbaren ViewModels, das ist das Ziel auf das man hinarbeitet in der Welt der WPF und dies ist mit Datasets einfach nicht möglich wodurch man früher oder später dann gezwungen wir erst wieder umzulernen, warum also nicht gleich anders lernen.

    Aber wie gesagt, gerne mach ich ein Video über füge ein Kapitel hinzu, bitte bescheid geben.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Ja das ist ein verständliches Argument, nur wüsste ich nicht wie ich dann mit WPF:

    Eine Art Notizbuch erstellen kann, auf welches auch andere zugreifen können, ohne eine Richtige Datenbank im Hintergrund laufen zu lassen,
    wie ich dies mit Winforms realisieren kann weiß ich, nur ist das halt designtechnisch einfach grüze, wenn das so aber mit WPF nicht wirklich realisierbar ist, muss ich halt mit schlechtem Design leben und bei Winforms bleiben
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If
    Es ändert sich nichts daran wo die Daten liegen ob es ein WinForms Projekt oder ein WPF Projekt ist.
    Wie gesagt, es ist möglich, siehe hier z.b.
    msdn.microsoft.com/en-us/library/dd547149.aspx

    Aber ich möchte in meinem Tutorial gerne auf neue, performante, flexible und vorallem skalierbare Technologien und Frameworks zurückgreifen.

    Aber ich habe einen Vorschlag: solltest du Interesse haben alternative Ansätze zu sehen wie man es in der WPF macht oder besser gesagt wie ich es machen würde kannst du gerne einen Thread hierfür im WPF Bereich erstellen und wir gehen das vorab schon mal durch.

    Schreib einfach dazu WIE du die Daten gerne Abrufen möchtest und welche. Vieleicht ein Codeschnipsel wie du es bisher unter WinForms gemacht hast und ich mache das WPF equivalent dazu.

    Vieleicht änderst du dann sogar deine Meinung, wer weis.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Jo, ich täte auch davon abraten, Datasets in Wpf zu benutzen.
    Nicht weil sie veraltet wären oder schlecht skalierbar, sondern weil sie einfach vom Wpf-BindungsSystem ungenügend unterstützt werden.
    Ich persönlich finde das überaus schade, dass Microsoft hier die einzige Möglichkeit, ein relationales Datenmodell auch ohne Datenbank zu persistieren, quasi abschafft.
    Tatsächlich gäbe es eine ziemliche Bandbreite an Problemstellungen, die mit typDataset + ohne Datenbank lösbar wären:
    Notizbuch, Addressbuch, Passwort-DB, Tätigkeiten-Logger, Sql-Übersetzer, Regextester, Vokabel-Trainer, etc..
    Halt kleine Datenverarbeitungen, die einerseits ein relationales Datenmodell erfordern, bei denen andererseits aber jede Datenbank ein grotesker Overhead ist, sowohl was Umständlichkeit als auch Resourcen-Frass angeht.
    Und der ausserdem die Portabilität extrem beeinträchtigt.

    Wie dem auch sei: Wpf spielt da nicht mit - der Binding-Designer zeigt zB die SpaltenNamen nicht an.
    Kann man natürlich trotzdem gegen an-programmieren, täte ich aber nicht empfehlen: das wird höchst mühsam und fehleranfällig.
    Auch wenn's offtopic ist, aber damit ich es auch verstehe, da ich ganz am Anfang meiner WPF-Entwicklung stehe: Was meinst Du mit

    ErfinderDesRades schrieb:

    der Binding-Designer zeigt zB die SpaltenNamen nicht an
    Wenn ich einem leeren WPF-Projekt ein tDS hinzufüge, da meine DataTables reinhaue, das Projekt kompiliere und dann aus den Datenquellen ein DataGrid auf's ... öhm ... Formular kann man da wohl nicht mehr sagen ... auf's MainWindow ziehe (nicht hauen, ich weiß, dass man das besser in XAML selber schreiben sollte), erhalte ich ja ein quasi DGV-look-a-like DataGrid mit den Tabellenspaltennamen und dem korrekten Binding.

    Der tDS-Designer verhält sich so wie in WinForms-Projekten. Also wirst Du das beides nicht meinen. Aber was dann?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    Hey - den kannte ich noch garnet! :thumbsup:

    Nein, allerdings meinte ich andere Arten zu binden, nämlich dass das tDs iwo im Viewmodel angesiedelt ist.

    Aber nu hab ich einen neuen Ansatz - vlt. kann man damit doch noch was reissen.
    Ich stehe aber gleich vorm nächsten Problem: Ich kann im Xaml den typisierten DataRow-Typen nicht angeben, weil das eingeschachtelte Klassen sind. Hab zwar im INet gelegentlich gelesen, dasses inzwischen formulierbar ist, nur die Beispiele haben bei mir nicht kompiliert.
    Hallo Leute

    Ja, wie @VaporiZed schon schrieb kann auch der Designer unter WPF das meiste.
    Und... macht nix wenn du Form sagst. In WPF sind es hald Window aber jeder weis ja was du meinst.

    Es gibt zwei Gründe warum ich es nicht in meiner Reihe durchnehme:
    • Wir wollen ja im Endeffekt später zu MVVM und da machen wir dann nicht mehr viel mit dem Designer
    • Ich fand und finde auch heute noch diese Klicki-Bunti Geschichten überaus nervig. Ich bin da vieleicht eigen, aber wenn ich programmieren dann will ich mit meinem Code bestimmen was wie wo und wann passiert und bin kein Freund davon dies aus der Hand zu geben. Ich weis, da bin ich eigen, ich konnte mich aber noch nie mit diesen tDs und allem was dran hängt anfreunden. Verzeiht mir das bitte.
    Da wir in der WPf ja das Ziel haben früher oder später von den Vorteilen der Trennung zwischen View und Code zu profitieren (und das tut man in der Tat) möchten wir solche Unternehmungen eigentlich vermeiden.
    Vorallem wenn es auch anders geht.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hallo nochmal

    Ich habe gerade ein Beispiel gemacht wie einfach es sein kann ein Notizbuch (sind jetzt nicht alle Funktionen enthalten wie z.b. neuanlage) zu erstellen.
    Unter zuhilfenahme des xmlDataProvider ist das eine einfache Sache.

    Ohne viel Code, mit Binding und Designtimesupport inkl. Intellisense. Was will man mehr.

    Grüße
    Sascha
    Dateien
    • WpfNotizbuch.zip

      (52,01 kB, 53 mal heruntergeladen, zuletzt: )
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Nofear23m schrieb:

    Ja, wie @VaporiZed schon schrieb kann auch der Designer unter WPF das meiste.
    Hmm - also ich komme mit der aufs Window gezogenen DataTable nicht recht weiter.
    Der generierte Code ist stark Anti-MVVM, und beim Umstricken habich wieder meine alten Problem, dass Binding-Picking nicht möglich ist, und das Datentypen garnet formulierbar sind.
    Letzteres bewirkt, dass man auch beim Entwerfen von DataTemplates keine Intellisense oder sonstige Unterstützung hat.
    Und ohne derlei Unterstützung ist Wpf einfach jämmerlich - da kann man denn auch im NotePad-Editor programmieren - also da hat man ja unter vb6 schon sicherer gecodet.

    Ich guck mir mal das mittm XmlDataProvider an, aber ich glaub, auch der bietet keine DesignTime-Info über die Daten, die da bereitgestellt werden.

    Oh - cool - der XmlProvider scheint Daten-Informationen bereitstellen zu können.
    Zwar bei weitem nicht in dem Umfang, wie ein relationales typisiertes Datenmodell es könnte (Xml kann ja nur String), und eben nur hierarchisch-nicht-relational - aber sicherlich kann man damit schoma eine Menge anfangen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    ErfinderDesRades schrieb:

    Der generierte Code ist stark Anti-MVVM

    Wie jetzt? Logisch.
    Alles was ich im Designer mache kann gar nicht MVVM tauglisch sein. Wie soll das funktionieren wenn ein View von einer Logik getrennt ist.

    ErfinderDesRades schrieb:

    Oh - cool - der XmlProvider scheint Daten-Informationen bereitstellen zu können.

    Naja, auch nicht so meines, aber wenns mal schnell gehen muss kann man den sicher hier und da mal verwenden.

    Wie gesagt, das Ziel ist ein anderes =O

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hi @Nofear23m
    Dein Tut über Binding hat mich beindruckt.
    Ich weis - dieses Kapitel ist sehr umfangreich und hat das Video in die Länge gezogen...
    Mir ist aber aufgefallen, das zwei Arten von Binding nicht behandelt wurden:
    Multi- und Prioritybinding
    Wären m.M. vlt. noch einen Nachtrag wert :)
    Hallo @VB1963

    Das hast du richtig beobachtet. Ich möchte mit Binding nicht ZU schnell voranschreiten. Ich denke das Binding ansich sollte man etwas "sickern".
    Jeder soll das mal probieren und versuchen etwas zu verstehen.
    In der Tat werde ich am Ende des Binding-Kapitels ein Bonusvideo 8o über MultiBinding machen. (Ups, jetzt hab ichs verraten)

    PriorityBinding lasse ich allerdings völlig weg. Zum ersten deshalb weil man es wirkich sehr selten benötigt zum anderen weil es jeder der Binding versteht auch in Minuten im Netz nachschlagen kann und dann auch versteht.
    Bonus deshalb weil ich der Meinung bis dan man auch Multibinding eher selten benötigt. Aber hier und da dennoch nicht schlecht ist.

    Aber echt super mitarbeit. Top!!

    Schöne Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hallo Leute

    Ein neues Kapitel ist wieder Online.

    Diesmals mit einer kleinen Zusatzüberraschung für alle die brav das Video gucken. =O
    Ich wünsche euch viel Spass und freue mich natürlich wieder auf Feedback.

    Diesmal habe ich nichts geschnitten, ich dachte ich habe nun bereits etwas Übung, hoffe es passt trotzdem.

    Tutorial <WPF lernen/>

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hi,
    ich hab mal eine allgemeine Frage (nicht schlagen wenn ich es irgendwo überlesen habe).
    Das MVVM Konzept besagt ja (im groben) die Trennung von Gui und Daten durch die Zwischenschicht ViewModel.
    Wenn ich nun mehrere Window habe, sagen wir zum Hinzufügen von Daten oder zum Löschen von Daten...
    Muss ich dann für jedes Window ein eigenes ViewModel haben?
    Und muss ich dann im Viewmodel wieder die Properties anlegen, die im Model ändern will?
    Ist das dann nicht doppelt gemoppelt?
    Im Moment hab ich es so, das die View direkt ans Model gebunden ist, da dies gegen MVVM verstößt möchte ich das gerne richtig machen.
    Danke für nen kurzen Hinweis...
    "Hier könnte Ihre Werbung stehen..."
    Jo, ist oft doppelt gemoppelt, und nervtötend redundant, ist sog. "BoilerPlate-Code".
    Und wenn man da nicht eine ausgefeilte Strategie verfolgt, kommt man da bei Zufügungen/Löschungen auch an Grenzen des Machbaren.
    Zum Glück verfügt NoFear über eine geeignete Strategie, indem er glaub ListCollectionView Events abonniert, und so Zufügungen/Löschungen im Viewmodel gleich überträgt ins Model. (vlt. nicht ganz korrekt wiedergegeben, aber so ähnlich, und es ist trickreich, funzt dann aber zuverlässig und allgemeingültig)

    MichaHo schrieb:

    da dies gegen MVVM verstößt möchte ich das gerne richtig machen.
    definiere "richtig".
    Ich definiere "richtig" so, dass man getrost ins Model binden darf, um o.g. BoilerPlate einzusparen.
    Solange das möglich ist - nicht länger. :D
    Nach meiner Erfahrung ist das in vielen Fällen möglich, aber bei anspruchsvolleren Guis hörts dann iwann auf, und man muss dann doch ein Viewmodel zwischenschieben.
    Solange es möglich ist, spart man damit eine Menge frustrierenden BoilerPlate, der ja auch immer so schwer zu verstehen ist, weil er eiglich nichts sinnvolles macht.
    Und wenns dann nötig wurde, ein VM zwischenzuschieben, ist das dann auch nicht mehr unverständlich/frustrierend, sondern ist sinnvoller Code, der auch was macht.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()

    @ErfinderDesRades OK, Danke Dir, also ist es keine Schande bei einer einfachen Aufgabe wie AddNewBlaBla direkt ans Model zu binden...
    Prima, dann komm ich schon mal weiter...
    In dem Fenster um das es hier geht, gabs eh nur 2 Knöppe, einer speichert und einer cancelt... und es wird nur 1 Propertie gespeichert.
    wollte aber mal scheun, ob ich das nicht mit einem extra Fenster mache, sondern als UserControl direkt im ShowFenster... Na mal gucken...
    "Hier könnte Ihre Werbung stehen..."

    MichaHo schrieb:

    Das MVVM Konzept besagt ja (im groben) die Trennung von Gui und Daten durch die Zwischenschicht ViewModel.
    Wenn ich nun mehrere Window habe, sagen wir zum Hinzufügen von Daten oder zum Löschen von Daten...
    Muss ich dann für jedes Window ein eigenes ViewModel haben?

    Wenn wirklich M-V-VM vollzogen wird dann benötigt du tatsächlich ein eigenes ViewModel. Im Grunde hast du IMMER für jeden View auch ein ViewModel. Wie die benamsung bereits vermuten lässt.

    Bei MVVM ist das Model vom View getrennt. Im Regelfall hat auch das View keinen Verweis auf das Model.
    (Bei M-V-VM ist jeder Layer auch ein eigenes Projekt, und nicht alles in einem, sonst hat mvvm keinen Sinn, denn das PAttern besagt das diese Layer getrennt sein müssen.)
    Warum hat es keinen Verweis? Weil ich nicht abhängik sein möchte. Tausche ich das Model oder ein PRoperty oder einfach einen Datentypen, muss ich wieder das View ändern was mitunter mit Problemen verbunden sein kann. Was ist wenn ich das Model gar nicht in der Hand habe, was wenn ich einen Webservice bemühe und hier ist ein Model vorgegeben.
    In dein WpfNotes Beispiel (ACHTUNG: kein MVVM) habe ich ja auch INotifyPRopertyChanged im Model, was man normalerweise nicht hat, auch wenn ich mit Datenbanken und/oder EntityFramework arbeite habe ich die Schnittstelle nicht im Model. Somit habe ich keine Benachrichtigung für die WPF. Also wie will ich das ohne zwischenlayer überhaupt machen. Ich benötigt also ein ViewModel.

    MichaHo schrieb:

    Und muss ich dann im Viewmodel wieder die Properties anlegen, die im Model ändern will?
    Ist das dann nicht doppelt gemoppelt?
    Im Moment hab ich es so, das die View direkt ans Model gebunden ist, da dies gegen MVVM verstößt möchte ich das gerne richtig machen.

    Klar, kann man so sehen, wenn man genauer hinsieht merkt man das es eben nicht so ist. Auch @ErfinderDesRades meint immer es wäre doppelt gemoppelt, was es im Grunde nicht ist. Es sieht auf den ersten Blick nur so aus weil ich ein und das selbe PRoperty oft im ViewModel wie im Model definiert habe.
    1. habe ich es im Model ohne INotifyPropertyChanged ja nicht mehr als "Full Property" mit Getter und Setter sondern ein "Einfaches" in der kurzen Schreibweise.
    2. Leite ich es nur weiter bzw. fülle es nur noch

    Beispiel für ein Property in einem ViewModel:

    VB.NET-Quellcode

    1. Private _meinModelObject As Note
    2. Public Propery NotizText as String
    3. Get
    4. Return _meinModelObject.Content
    5. EndGet
    6. Set
    7. _mainModelObject.Content = value
    8. RaisePropertyChanged()
    9. End Set


    Wer sagt denn das ich im View eine Eigenschaft aus dem Model genau so anzeigen will wie es im Model drinnen ist.
    Vieleicht habe ich in der Datenbank etwas als String gespeichert was ich im View mit einem DateTimePicker darstellen und Binden möchte. Dann benötige ich für die Bindung ja ein Property mit dem passenden Datentypen dazu. Deshalb macht man ein ViewModel dazwischen, damit mal einfach flexibel ist. Auch wenn man dafür etwas mehr schreiben möchte.

    ErfinderDesRades schrieb:

    definiere "richtig".
    Ich definiere "richtig" so, dass man getrost ins Model binden darf, um o.g. BoilerPlate einzusparen.
    Solange das möglich ist - nicht länger.

    Wir hatten schon oft darüber gesprochen und ich wiederhole mich wirklich ungern. Das ist NICHT die definition des Pattern. Da gibt es auch keinen Spielraum für interpretierungen, ansonsten ist es KEIN M-V-VM !!!!!!!!

    Aber das hatten wir ja schon. Von mir aus nenne es EDR-VM aber bitte nicht MVVM. Das MVVM Pattern gibt genau eine Richtlinie vor.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Nofear23m“ ()