Entity Framework - MVVM - Verständnisfrage und ein paar Problemchen

  • WPF

Es gibt 29 Antworten in diesem Thema. Der letzte Beitrag () ist von kaifreeman.

    naja, zu einem viertel sarkastisch, und zu 3/4 ernstgemeinte Frage.
    Weil wenn ein Fody dir abnehmen kann, INotifyPropertyChanged selbst zu implementieren, warum soll ein anderer Fody dir IEditableObject nicht abnehmen können?
    Bei INotifyPropertyChanged ist der Fody-Nachteil dabei nur theoretischer Natur - er "bewahrt" dich auch davor, INotifyPropertyChanged richtig zu verstehen (diese Überlegung ist das sarkastische Viertel).

    kaifreeman schrieb:

    Was wäre wenn ich das Binding auf Oneway setzte mit dem Klick auf den "Save" Button im ViewModel die Behandlung mache um die Datenänderung abzugreifen und dann an die View zu geben das würde doch nicht gegen das MVVM verstoßen oder?
    Nö - wäre gangbar.
    Ist halt nur ausserhalb des Standards, und ich halte solch nicht für empfehlenswert.

    In meiner Welt savet ein Save-Button alle Änderungen, die ich zwischenzeitlich gemacht habe, nicht einen einzelnen Detailview. Ich kann auch das Saven bleibenlassen, dann habich alle neulichen Änderungen gecancelt.

    Aber ein Detailview, den ich eingegeben habe, der ist eingegeben, das brauche ich nicht extra bestätigen (und kanns daher auch nicht vergessen).
    Aber wie du wolle - mach dein Binding OneWay, und den DataSource-Update per Button.



    Edit: hast du mal einen Link zu einer Fody-Dokumentation? Täte mich interessieren, was Fody ist, und wasses kann.
    (naja, ich kann auch googeln, aber vlt. kannst du ja eine Doku empfehlen)
    Der Vorteil von Fody ist in diesem Fall das ich nicht für jede Property einen eigene PropertyChanged Event bereitstellen muss, sicher verhindert es das gesamtheitliche Verstehenvon INotifyPropertyChanged nur in diesem Fall überwiegen meiner Meinung nach die Vorteile es quasi "quick and dirty zu machen"
    Auf Fody bin ich im Zuge meiner Recherchen zum Thema gestoßen github.com/Fody/Fody es ist anscheinend recht mächtig und bietet eine große Anzahl an Möglichen "injections" sprich Addings an die man benutzen kann wobei ich zugeben muss das ich mich noch nicht wirklich detailliert damit auseinandergesetzt habe.

    Ich werd mir das noch durchgrübeln wie ich das nun wirklich realisieren möchte dafür spricht mal sicher das man nicht immer alles bestätigen muss mal gucksen...

    Danke zwischenzeitlich für deine Hilfe bei dem Thema bin wieder einen großen Schritt weitergekommen.
    mfG.
    Stephan
    och - ich find Fody nicht quick & dirty.
    Haufenweise INotifyPropertyChanged zu implementieren bedeutet, an ganz vielen Stellen immer das eigentlich gleiche zu schreiben. Sowas nennt man "Boilerplate-Code", und wenn man solch Lästigkeit loswerden kann, ist das auf jeden Fall ein Gewinn.
    Weil BoilerPlate-Code ist nicht nur lästig, sondern es macht eine Code-Datei auch deutlich unübersichtlicher, wenn sie mw. 300 statt nur 150 Zeilen enthält.

    Aber die Kosten-Seite muss man auch sehen. Ist eiglich nur die Abhängigkeit von einer weiteren Dll - sowas setzt die Portabilität immer bischen runter.
    Und ein richtiges Verständnis des INotifyPropertyChanged-Prinzip kann man sich ja trotzdem noch erarbeiten.
    Genau das hätte mir auf Basis dieses Vorschlags hier: msdn.microsoft.com/de-at/library/ms743695(v=vs.110).aspx geblüht.
    Allerdings hab ich mir mit "Fody" jetzt durchaus ein kleines Problem aufgerissen wenn ich den Dialog so betreiben möchte wie du vorschlägst also ohne dediziertes Speichern zu klicken
    erhalte ich natürlich keine Meldungen das sich in meiner Collection ein Property geändert hat was ich somit nicht in eine "Reaktion" zum Speichern umsetzen kann.

    Da muss ich mir jetzt überlegen doch INotifyPropertyChanged "richtig" zu benutzen oder bei Form Close einfach das speichern auszulösen.

    Auf alle Fälle muss ich definitiv eines sagen mit MVVM wird es um einiges leichter zu programmieren ich habe mich anfangs etwas gestreut aber jetzt flutscht es.
    mfG.
    Stephan
    ich verstehe nicht.
    aber ich hab ja auch 2 Vorschläge gemacht:
    1) mit Extra-Dialog zum Editieren und ggfs canceln
    2) standard-DetailView, wo die Werte halt übernimmt, die man reinschreibt.

    Für letzteres musst du garnix tun - Normales Databinding übernimmt die Werte, die man reinschreibt. Du musst nicht reagieren.

    Und ein besonderes Fody-Problem sehe ich nicht.
    Doch ich muss reagieren die Änderungen am ListCollection bzw. Observable gegen ohne Update sonst nicht zurück in die DB liegt wahrscheinlich am .local aufruf aber einmal savechanges aufgerufen und gut ist.

    Für meine Wunschlösung habe ich mittlerweile auf die Commit und Cancel Methoden der Listcollection zurückgegriffen klappt somit auch wunderbar.
    mfG.
    Stephan
    Dagegen spricht das sich die Collection innerhalb des Programmes sofort ändert wenn eine Property geändert wird aber das Rückspeichern in die DB sonst nicht angestoßen wird. Das könnte z.b. zum Verhalten führen der User ändert einen Eintrag von "A" nach "B" arbeitet im Programm weiter und kann überall "B" auswählen beim nächsten Programmstart steht aber überall "A" wie gesagt habe abgefangen und somit kann keine Inkonsistenz entstehen.
    mfG.
    Stephan