none
MVVM - das richtige für mich!? RRS feed

  • Frage

  • Hallo

    Eine allgemein gehaltene Frage mit der Hoffnung viele verwertbare Antworten zu bekommen.

    Ich möchte eine neue, relativ große Software per WPF & VB.NET entwickeln (Kunden, Artikel, Auftragsverwaltung)

    Jetzt schlage ich mich in der Theorie schon länger mit MVVM herum. - Grundsätzlich ist mir die Vorgehensweise klar, doch ich finde es für mich doch mehr kompliziert als einfach. (Im Gegensatz zum Code Behind). Da ich das Projekt selbst entwickle und ich auch nicht vorhabe jemand anderen mit Coding zu beauftragen, stelle ich mir jetzt die Frage, ob MVVM sein "muss".

    Was haltet Ihr davon? - Was würdet Ihr machen (und vor allem warum)

    Danke für eure Inputs

    Freitag, 21. September 2012 11:46

Antworten

  • Du hast in Deinen Ausführungen die Tests vergessen. Im prozeduralen CodeBehind sind automatische Tests nur bedingt oder mit sehr hohem Aufwand über die Oberfläche möglich. Mit MVVM sind die üblichen für Klassen/Objekte angewandten Techniken, z.B. Unit Tests problemlos ohne zusätzlichen durch die UI bedingten Aufwand möglich.
     
    Deine Argumentation mit dem “neuen Button” bedeutet, dass die Geschäftslogik zu ändern ist, d.h. es entsteht eine neue Anwendung mit anderen Anforderungen. Da ist natürlich auch der ViewModel zu ändern.
     
    Wenn sich jedoch die Geschäftslogik nicht ändert, sondern nur die Oberfläche, z.B. eine neue Anordnung der Oberflächenelemente auf anderen Fenstern, Seiten, Panelen, UserControls, dann kann das ein Designer ohne zusätzlichen Programmieraufwand im CodeBehind machen. Auch sind dann keine zusätzlichen Tests der Geschäftslogik erforderlich. Im Gegensatz dazu sind bei Arbeit ohne MVVM nur mit prozeduralen Methoden im Codebehind erneut umfangreiche Tests erforderlich, auch wenn sich die Geschäftslogik nicht geändert hat.
     
    WPF und Silverlight-Anwendungen programmiere ich nur noch mit MVVM. In anderen Anwendungen, z.B. ASP.NET nutze ich die prinzipielle Herangehensweise analog – Auslagerung der Geschäftslogik in einen Viewmodel bzw. Presenter und DataBind im PreRender.
     
    --
    Viele Gruesse
    Peter
    • Als Antwort markiert Zero-G. _ Samstag, 22. September 2012 09:35
    Samstag, 22. September 2012 08:41

Alle Antworten

  • Hi Zero,

    WPF ist so ausgelegt das es sehr gut mit MVVM zusammen arbeitet. Hier mal eine Einführung zu MVVM.

    Du solltest auf jeden Fall Logik, Daten und Darstellung trennen, was alles wider verwendbarer macht.

    Also möglichst "nichts" im Code Behinde packen.

    MFG

    Björn

    Freitag, 21. September 2012 13:08
  • Ich behaupte, dass bei Kenntnis von MVVM die Programmierung einer WPF- oder Silverlight-Anwendung einfacher ist als nur prozedural im CodeBehind zu arbeiten. Es ist zwar ein geringfügig höherer konzeptioneller und auch Programmieraufwand am Anfang, aber, dieser Aufwand lohnt sich bei Fehlersuchen und –beseitigungen und vor allem bei Anpassungen an veränderte Kundenwünsche.
     
    --
    Viele Gruesse
    Peter
    Freitag, 21. September 2012 14:32
  • Hi Peter,

    ich muss gestehen, ich kann deiner Argumentation nicht ganz folgen.

    Grade wenn das Softwareprojekt größer ist, habe ich einen geringere Programmieraufwand, da ich keine Logik/Daten im CodeBehinde habe und diese Logik/Daten an anderer Stelle verwenden kann. (Umsetzung der SOLID Prinzipen vorausgesetzt.)

    Auch sehe ich keinen höheren konzeptionellen auf wand, da ich ja ein bestehendes Konzept verwende (MVVM bietet hier natürlich kein rundum Sorglos-Paket aber schon mal eine Grundlage) . Bei größeren  Projekten muss ich auch beim CodeBehinde mir Gedanken über das Konzept.

    Hier tauchen dann meist Problem auf wie tausche ich Daten zwischen View und wie aktualisieren ich den View wenn das Andere die Daten geändert hat.

    Ich muss auch gestehen alle Projekte, die ich bis jetzt gesehen habe, die viel im CodeBehinde gemacht haben, hatten keine Struktur, keine Objekte, Daten direkt in den Controlls, ellenlange Methoden, massig redundanten Code u.s.w.. 

    Kurz sie waren die Hölle.

    MFG

    Björn

    Freitag, 21. September 2012 15:57
  • Prozedural im CodeBehind verleitet, ohne Struktur, ohne Objekte usw. zu programmieren. Und dieses Chaos bedeutet anfänglich weniger Aufwand als bei MVVM, wo man gezwungen ist, sich von Anfang an Gedanken über Strukturierung, Kapselung, Interfaces usw. zu machen. In diesem Sinne sollten meine Bemerkungen verstanden werden.
     
    --
    Viele Gruesse
    Peter
    Freitag, 21. September 2012 17:13
  • Guten Morgen

    Ich hätte gehofft, dass ein paar contra Punkte von MVVM auch kommen...

    Was ich hier gelesen habe und auch im Netz immer wieder lese, ist dass das Design bei MVVM eine Rolle spielt. Das kann ich von der Überlegung nicht nach vollziehen, denn WPF kann ich auch jeder Zeit Design-Technisch verändern - doch der Codebehind (z.b.) Click_Event Handler bleibt und es hat sich im Hintergrund nichts geändert. - Wenn der Endkunde einen neuen Button haben möchte, dann muss der sowohl bei der MVVM Technik ausprogrammiert werden, sowohl auch im Code Behind.

    Das Thema Redundanter Code ist auch keine schlagende Argumentation, denn das hat was mit dem Durchdenken des Programms selber zu tun, aber nicht mit MVVM.

    Wiederverwertbarkeit von Codeteilen ist auch kein MVVM Vorzug, wenn man bedenkt, dass ich auch im Codebehind Klassen generieren kann - Bzw. mehrere Projekte verwalten kann, die eben auch wiederverwertbar sind.

    Wenn ich MVVM grundsätzlich mal verstanden habe, binde ich an den Datencontext des UserControls/Form/Page usw. eine Klasse. Diese Klasse enthält dann meine Properties, die wiederum per MVVM Technik an z.B. eine TextBox gebunden wird. Das wiederum bedeutet, dass man ein Relaying benutzt. - Das wird aber genauso im CodeBehind benutzt (wenn ich jetzt nicht falsch liege). Beim Datenübergeben binde ich nach wie vor Daten an eine Klasse, die eben dann nicht bei Sub New übergeben werden, sondern die Properties werden direkt angesprochen und dann das ganze an den DataContext gebunden.

    Mir erschließt sich da kein (bitte nicht steinigen) definitiver Unterschied an der Grundtechnik -> Es bleibt doch im Hintergrund ähnlich dem alten System!? -> Aber mit eindeutig mehr Overhead.

    Wenn mehrere Leute daran arbeiten (Ein Designer, ein Entwickler) dann hat es seine Vorteile, weil beide unabhängig von einander arbeiten können und sie "nur" über die Anzahl & Namen der Textboxes bescheid wissen müssen. -> Beim CodeBehind ist das nicht möglich, weil eben die Handler alle direkt erzeugt werden und somit der Designer erst fertig sein muss.

    Tja, jetzt bin auf euren Response gespannt. -> Ich sehe die Steine schon fliegen ;)

    DANKE

    Samstag, 22. September 2012 06:54
  • Du hast in Deinen Ausführungen die Tests vergessen. Im prozeduralen CodeBehind sind automatische Tests nur bedingt oder mit sehr hohem Aufwand über die Oberfläche möglich. Mit MVVM sind die üblichen für Klassen/Objekte angewandten Techniken, z.B. Unit Tests problemlos ohne zusätzlichen durch die UI bedingten Aufwand möglich.
     
    Deine Argumentation mit dem “neuen Button” bedeutet, dass die Geschäftslogik zu ändern ist, d.h. es entsteht eine neue Anwendung mit anderen Anforderungen. Da ist natürlich auch der ViewModel zu ändern.
     
    Wenn sich jedoch die Geschäftslogik nicht ändert, sondern nur die Oberfläche, z.B. eine neue Anordnung der Oberflächenelemente auf anderen Fenstern, Seiten, Panelen, UserControls, dann kann das ein Designer ohne zusätzlichen Programmieraufwand im CodeBehind machen. Auch sind dann keine zusätzlichen Tests der Geschäftslogik erforderlich. Im Gegensatz dazu sind bei Arbeit ohne MVVM nur mit prozeduralen Methoden im Codebehind erneut umfangreiche Tests erforderlich, auch wenn sich die Geschäftslogik nicht geändert hat.
     
    WPF und Silverlight-Anwendungen programmiere ich nur noch mit MVVM. In anderen Anwendungen, z.B. ASP.NET nutze ich die prinzipielle Herangehensweise analog – Auslagerung der Geschäftslogik in einen Viewmodel bzw. Presenter und DataBind im PreRender.
     
    --
    Viele Gruesse
    Peter
    • Als Antwort markiert Zero-G. _ Samstag, 22. September 2012 09:35
    Samstag, 22. September 2012 08:41
  • Hi Zero-G,

    beim Binden an den Datenkontext bis du schon bei WPF typischen Implementierungsdetails.
    Das MVVM Pattern sagt erst mal nichts anderes als das ich die Anzeige (View), Logik (ViewModel) und Daten (Model) trenne. Die View das ViewModel kennt und das ViewModel das Model.

    Beim CodeBehinde wird Klassischer weise davon Ausgegangen, das dort auch irgendwelche Logik enthalten ist.

    Um vielleicht mal ein Beispiel zu geben.

    Wenn ich eine Liste von Auftragen hab und diese wiederum eine Liste von Artikel umfasst.

    Kann ich z.B. wenn ich die Offenen Auftrage in einer Liste darstelle, den Benutzer einen Button anbieten, mit dem er offene Auftrage abschließt. Hier wird dann z.B. der Gesamtpreis berechnet und z.B. ein Rabatt.

    Jetzt kann ich hingehen und die Berechnung im Klick Event machen (CodeBehinde) oder ich rufe dort die Methode eine Klasse (VM) auf die den Auftrag kennt und die Berechnung vornimmt.

    Wenn ich nun eine Detailansicht habe in dem die Artikel für den Auftrag angezeigt werden sollen und die mir auch erlauben soll den Auftrag abzuschließen. Würde ich beim CodeBehind den Code aus der Listenansicht nochmal schreiben müssen (Kopieren) statt einfach die Klassen Methode aufzurufen.

    WPF macht jetzt nicht anderes als dir zusätzliche Methoden/Pattern bereit zu stellen um die Trennung von View ViewModel und Model zu vereinfachen. Diese kannst du verwenden musst es aber nicht. Z.B. das ICommand Interface wenn ich jetzt eine Methode habe die ich immer ausführen kann ist CanExecute und CanExecuteChange nicht nötig. Ob ich jetzt das Interface Implementiere und es an einen Button binde oder ich das Button Click Event abfange und dort eine Methode des VM aufrufe bleibt mir überlassen. Es entspricht aber beides noch dem MVVM Pattern. (Bzw kann entsprechen).

    MFG

    Björn

     

    Samstag, 22. September 2012 12:57
  • Ergänzend noch ein anderer Einsatzfall.
     
    Die Geschäftslogik verwaltet Zustände, die in der Oberfläche üblicherweise an unterschiedlichen Stellen genutzt werden. Dazu zählen vor allen Sichtbarkeiten (Visibility), Nur-Lese-Zustände (ReadOnly), farbige Hintergründe usw. Im ViewModel wird nur eine Eigenschaft pro Zustand implementiert. Diese kann aber an vielen Stellen in der Oberfläche genutzt werden. Bei komplexeren Zuständen kann auch noch ein Converter genutzt werden. Prozedural im CodeBehind ist so etwas nur mit u.U. sehr viel mehr Code möglich.
     
    --
    Viele Gruesse
    Peter
    Samstag, 22. September 2012 16:33