.NET GUI

.NET Community für WPF, Silverlight und mehr!
Willkommen bei .NET GUI. Anmeldung | Registrieren | Hilfe | Impressum | Forumsregeln
in Suchen

The spirit of MVVM

Letzter Beitrag 08-05-2009 15:24 von winSharp93. 5 Antworten.
Seite 1 von 1 (6 Treffer)
Beiträge sortieren: Zurück Weiter
  • 08-04-2009 8:47

    • Norbert Eder
    • Top 10 Mitwirkender
      Männlich
    • Registriert am 04-09-2008
    • Graz / Austria
    • Beiträge 980
    • Punkte 14.949
    • ForumsAdministrator

    The spirit of MVVM

    Gerade einen recht guten Artikel auf codebetter.com zum Thema The spirit of MVVM gelesen, welchen ich euch ebenfalls empfehlen möchte. Sehr interessante Gedanken zu Fragen, die man sich dann doch auch selbst hin und wieder stellt.
    Abgelegt unter:
    • Beitragspunkte: 20
    • IP-Adresse ist Registriert
  • 08-04-2009 9:15 Antwort zu

    • BerndH
    • Top 10 Mitwirkender
      Männlich
    • Registriert am 12-03-2008
    • Beiträge 92
    • Punkte 1.620
    • Moderator

    AW: The spirit of MVVM

    Hab den Artikel gestern auch gelesen und fand ihn sehr gut. Momentan bekommt das Thema MVVM sehr viel Fahrt. Man merkt, dass WPF immer mehr Verbreitung findet. Die MVVM Frameworks schiessen wie Pilze aus dem Boden. Einerseits finde ich das gut, da man viel lernen kann und sieht wie unterschiedliche Lösungsansätze aussehen. Andererseits wird es für den Einsteiger immer schwieriger sich in dieser Vielfalt zurechtzufinden. Es gibt halt nicht DEN MVVM Weg.
    Zu dem Thema kann ich auch die aktuellen Artikel von Rob Eisenberg empfehlen, z.B. MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
    Blog: C and it's sharp - http://berndhengelein.de
    • Beitragspunkte: 20
    • IP-Adresse ist Registriert
  • 08-04-2009 9:20 Antwort zu

    • Norbert Eder
    • Top 10 Mitwirkender
      Männlich
    • Registriert am 04-09-2008
    • Graz / Austria
    • Beiträge 980
    • Punkte 14.949
    • ForumsAdministrator

    AW: The spirit of MVVM

    Da stimme ich dir auf jeden Fall zu.

    Die Sache ist, dass MVVM eben nur ein Pattern ist. Und Patterns sind eine Vorlage, die an das jeweilige Einsatzgebiet angepasst werden müssen und keine Allgemeingültigkeit besitzen. Dann kommt noch dazu, dass es sich wie bei Ärzten verhält. Frag 3 Leute, die sich damit auskennen und du bekommst 4 Meinungen. 

    Für einen Einsteiger ist das auf jeden Fall äußerst schwierig:
    a) nämlich den richtigen Einstiegspunkt zu finden
    b) das Pattern selbst anzupassen und zu erweitern

    Ich merke es ja bei mir selber auch: Jedes Mal wenn ich glaube den perfekten Weg gefunden zu haben komme ich wieder drauf, dass es anders vielleicht doch besser gewesen wäre oder zumindest Teile davon anders gelöst werden könnten. Aber damit werde ich wohl nicht alleine im Wald stehen.

    • Beitragspunkte: 20
    • IP-Adresse ist Registriert
  • 08-04-2009 14:32 Antwort zu

    • winSharp93
    • Top 25 Mitwirkender
      Männlich
    • Registriert am 08-03-2009
    • Freiburg
    • Beiträge 40
    • Punkte 750

    AW: The spirit of MVVM

    >> Aber damit werde ich wohl nicht alleine im Wald stehen.
    Nein, auf keinen Fall Smile

    Es scheinen sich aber auch schon zwei grundverschiedene Ansätze herauszukristallisieren, die jedoch noch nicht wirklich getrennt werden:
    • Für jedes (User-)Control existiert ein ViewModel (oder "Presentation Model"); z.B. MainWindowViewModel, OptionsTabPageViewModel
    • Es existieren ViewModels, die von Controls dargestellt werden; z.B. AddNewCustomerViewModel, OverviewViewModel
    Während der erste Ansatz sehr UI-orientiert ist, und häufig zusammen mit der deklarativen Erzeugung des ViewModels im XAML-Code eines Controls einhergeht, abstrahiert das ViewModel im zweiten das UI.

    Die größten Unterschiede der beiden Ansätze offenbaren sich auch erst auf den zweiten Blick:

    Hält man sich an die erste Interpretation, sind ValueConverter etc. tabu: Das ViewModel liefert alle Daten vorformatiert an das UI; es ist bekannt, welcher Typ von Steuerelement an eine Property gebunden wird. Das UI wird auf diese Weise völlig logikfrei; alle Logik steckt im ViewModel.
    Das ViewModel gibt vor, wie die Daten angezeigt werden; nur das Aussehen bleibt über Styles etc. im View.

    Hingegen verfolgt der zweite Ansatz eine etwas andere Absicht: Ein passives View. Dabei ist es weniger wichtig, dass dieses keinerlei Logik enthält; diese sollte nur rein passiv sein. Was heißt das konkret? Es darf zwar Logik zur Formatierung existieren; diese darf jedoch ihre Parameter nur per DataBinding vom ViewModel beziehen.
    Die ViewModels repräsentieren hier also keine konkreten Controls, sondern vielmehr die Anliegen: Im ViewModel ist zwar vorgegeben, in welcher Form die Daten angezeigt werden (Liste, Baumstruktur, etc.), es formatiert jedoch keine Daten.
    So wird zwar unterm Strich das UI auch logikfrei, aber auf eine ganz andere Art.

    Ein praktisches, aber recht übersichtliches Beispiel:
    Es soll eine Person dargestellt werden, deren Name in der Form "Nachname, Vorname" angezeigt werden soll.

    Erster Ansatz (der XAML-Code reicht aus, um zu verdeutlichen, was ich sagen will):
    <UserControl ...>
    <TextBlock Text="{Binding Path=FullName}" />
    </UserControl>
    Zweiter Ansatz:
    <UserControl ...>
    <StackPanel Orientation="Horizontal">
    <TextBlock Text="{Binding Path=LastName}" />
    <TextBlock Text=", " />
    <TextBlock Text="{Binding Path=FirstName}" />
    </StackPanel>
    </UserControl>

    Was ist nun "richtig"?
    Ich weiß es ehrlich gesagt nicht

    • Beitragspunkte: 20
    • IP-Adresse ist Registriert
  • 08-05-2009 8:30 Antwort zu

    • Norbert Eder
    • Top 10 Mitwirkender
      Männlich
    • Registriert am 04-09-2008
    • Graz / Austria
    • Beiträge 980
    • Punkte 14.949
    • ForumsAdministrator

    AW: The spirit of MVVM

    Ich persönlich tendiere zur zweiten Variante, zumindest ist das meist der von mir gewählte Ansatz, wobei es immer wieder vorkommt, dass es Mischvarianten gibt. Es ist eben ein Pattern, welches an die eigenen Bedürfnisse angepasst werden muss. Aus meiner Sicht gibt es kein Richtig, aber auch kein Falsch. Es zählt die passende Variante für eine Anforderung.

    Abgesehen davon ist es nicht mein Wunsch, dass das ViewModel alles vorgibt. Es soll die Daten vorgeben, welche Aktionen möglich sind, auch was editierbar ist, was nicht etc. Wie das dann genau dargestellt wird (welches Format, whatever) ist dann Aufgabe der View. Hier habe ich dann auch kaum Probleme mit, wenn auch die View ein wenig Logik enthält (aber bitte nur, wenn es wirklich rein nur um den View-Bereich geht und unabhängig der Businesslogik ist). Damit kann Funktionalität gut getrennt werden und man verhunzt sich sein ViewModel nicht mit UI-Informationen.

    Vielleicht ist das ein recht rustikaler Ansatz von mir, aber bisher bin ich damit ganz gut gefahren.

    Ein Thema, das mir immer wieder Kopfzerbrechen bereitet, vor allem, weil es dafür 100te Ansätze gibt ist das Öffnen von Fenstern. An welcher  Stelle ist es richtig, wer darf das Fenster kennen usw. Man kann es die View machen lassen, einen eigenen WindowManager implementieren usw. Aber so den gefühlsmäßig 100% richtigen Ansatz habe ich hier auch nocht nicht. Was meint ihr?
    • Beitragspunkte: 20
    • IP-Adresse ist Registriert
  • 08-05-2009 15:24 Antwort zu

    • winSharp93
    • Top 25 Mitwirkender
      Männlich
    • Registriert am 08-03-2009
    • Freiburg
    • Beiträge 40
    • Punkte 750

    AW: The spirit of MVVM

    >> Ein Thema, das mir immer wieder Kopfzerbrechen bereitet, vor allem, weil es dafür 100te Ansätze gibt ist das Öffnen von Fenstern. An welcher Stelle ist es richtig, wer darf das Fenster kennen usw. Man kann es die View machen lassen, einen eigenen WindowManager implementieren usw. Aber so den gefühlsmäßig 100% richtigen Ansatz habe ich hier auch nocht nicht. Was meint ihr?

    Ich verwende da meine eigene Lösung, die ich auch auf meinem Blog veröffentlicht habe bzw. immer weitere Teile veröffentliche (das ganze ist Teil einer MVVM-Library).
    Falls es jemanden interessiert: Part 5: IUserInterface und Part 6: InteractingViewModel / IUserInteracter.

    Da ich diese Variante selbst entwickelt habe, "fühlt" sie sich für mich auch ganz ordentlich an.

    Das Ziel, das ich verfolge, ist, das View möglichst vom ViewModel fernzuhalten; dieses verfügt über einen so genannten "IUserInteracter", der Befehle wie Show und Close bereitstellt; unterm Strich geht es also in die Richtung "WindowManager".
    • Beitragspunkte: 5
    • IP-Adresse ist Registriert
Seite 1 von 1 (6 Treffer)
Powered by Community Server (Commercial Edition)    69° - Internet-Agentur München (CMS, ASP.NET, Webdesign)