Wie kann man wählen, KEIN Framework (Caliburn.Micro usw.) in einer bestimmten MVVM-Anwendung zu verwenden?

28

Ich habe einmal ein MVVM / WPF-Projekt gestartet, das schließlich erstellt und bereitgestellt wurde, und dafür habe ich viel über das Caliburn.Micro MVVM-Framework gelernt. Tatsache ist: Ich habe Caliburn.Micro dafür nicht verwendet und einige MVVM-Konzepte (insbesondere nur die ViewModelBaseund RoutedCommand-Klassen) selbst implementiert .

Jetzt wurde ich einem etwas größeren Projekt zugewiesen: sozusagen einer "Einzelbenutzer-Rich-Client-Offline-Desktop-Anwendung", und ich entschied mich für Caliburn.Micro. Und hier beginnt mein "Problem".

Ich habe in diesem berühmten Blog-Beitrag gelesen, in dessen Titel steht: "Wenn Sie MVVM verwenden, benötigen Sie ein Framework".

"Der Versuch, so etwas wie MVVM ohne Framework zu machen, ist eine enorme Arbeit. Tonnenweise doppelter Code, das Rad neu erfinden und die Leute dazu bringen, anders zu denken .

Zumindest mit einem Framework vermeiden Sie den doppelten Code und müssen das Rad hoffentlich nicht neu erfinden. So können Sie sich auf die Umschulung von Mitarbeitern konzentrieren. Der Umschulungsteil ist im Allgemeinen unvermeidlich, aber ein Framework bietet Installationscode und -struktur, was den Prozess vereinfacht. "

Ich würde der ersten Lesung zustimmen, aber meine tatsächliche Erfahrung mit Caliburn.Micro (CM) in meiner tatsächlichen Bewerbung ist ratlos und desorientiert. Das heißt, das Framework hat den Prozess überhaupt nicht einfacher gemacht, im Gegenteil. Das Lesen der sich ständig wiederholenden Beispiele von Rob Eisenberg in der eher (zu) informelle Dokumentation und versuchen zu schließen Nutzungsmuster aus den gewundenen zur Verfügung gestellten Proben und ihre ganz indirekte Klassen- und Interface - Beziehungen, wo die Dinge scheinen zu Arbeit zu gestalten , basierend auf Nebenwirkungen, scheint menschlich unmöglich, es sei denn, Sie sind ein erfahrenes Genie (Entschuldigung für die Beschimpfung, aber ich denke, Sie wissen, was ich meine).

Ganz zu schweigen davon, dass jedes der oben genannten trivialen Szenarien IoC-Container beinhaltet, mit denen ich noch nie gearbeitet habe und die ein Problem zu lösen scheinen, das ich möglicherweise noch nicht einmal hatte . Ich habe keine Lust, mehr Projektstunden damit zu verbringen, diese Dinge zu lernen, anstatt über meine Problem- und Anwendungsdomänen nachzudenken. Ich wollte nur eine Banane, aber CM gab mir einen Gorilla (IoC) mit einem Korb Bananen.

Jetzt, da ich überlege, zu meinem selbst erstellten MVVM-Framework zurückzukehren, das nur aus wenigen MVVM-spezifischen Klassen besteht, die ich tatsächlich implementieren möchte, möchte ich CM zumindest eine Chance geben, falls ich hier etwas verliere, oder nur einfach die Dinge "auf die falsche Art und Weise" aus purer Unerfahrenheit und Unwissenheit heraus zu tun. Die Frage ist also:

Es herrscht allgemeiner Konsens darüber, dass "Frameworks die Dinge einfacher und natürlicher machen". Wenn ich jedoch das Gegenteil erlebe, bedeutet dies, dass ich das Framework nicht verwenden sollte oder dass ich versuche, es falsch zu lernen? Gibt es einen Hinweis darauf, dass ich überhaupt kein Framework verwenden sollte? Oder gibt es einen "richtigen" Weg, um herauszufinden, wie CM für die einfache MVVM-Entwicklung verwendet wird?

frameworks wpf mvvm

— Heltonbiker
quelle

1

Persönlich wähle ich Elemente aus jedem Framework aus, um sie für bestimmte Verhaltensweisen zu verwenden, und ich ignoriere den Rest. Zum Beispiel verwende ich gerne Microsoft PRISMs EventAggregatorfür Messaging und NotificationObjectViewModelBase sowie MVVM Light RelayCommandfür Befehle. Das Wichtigste ist, zu identifizieren, welche Probleme das Framework für Sie lösen wird, und nur diese Lösungen zu verwenden. Sie müssen nicht die gesamte Framework-Bibliothek verwenden.

— Rachel

@ Rachel Ich hatte vor, diesen Ansatz mit Caliburn.Micro zu verwenden, konnte jedoch keine RelayCommandImplementierung finden (da er direkt an Methoden gemäß Konvention "bindet", anstatt an ICommand-Eigenschaften zu binden).

— Heltonbiker

Ich habe das Caliburn-Framework nie verwendet, da mir nicht gefallen hat, wie eng die Views mit der Model / ViewModel-Ebene verbunden zu sein scheinen. In Ihrem Fall sehe ich keinen Grund, warum Sie eine RelayCommandaus einer anderen Bibliothek nicht verwenden könnten, wenn die von Caliburn Micro verwendete nicht für Sie funktioniert.

— Rachel

@Rachel bezüglich "wie nah [caliburn] die Ansicht an die MVM-Ebene bindet", was genau meinst du? Was wäre die "nicht kalibrierte" Art, diese Schichten auf eine bessere, mehr MVVM-Art zu binden? (Ich bitte aufrichtig, weil ich derzeit nicht weiß).

— Heltonbiker

Ehrlich gesagt habe ich noch nie Caliburn Micro verwendet, daher fühle ich mich als schlechter Richter des Frameworks. Ich erinnere mich, dass ich den Eindruck hatte, dass die Ansicht zuerst erstellt wurde und für die Entscheidung der Code-Behind-Objekte verantwortlich war. Dies war ein Aspekt, den ich nicht mochte, da mir die View-First-Entwicklung nicht gefiel. Ein weiteres Problem waren die automagischen Bindungen, die davon abhingen, wie Sie XAML-Komponenten benennen, da ich der Meinung war, dass die Benutzeroberfläche zu stark mit der Business-Schicht verknüpft ist. Ich habe jedoch gute Dinge über das Framework gehört und würde nicht empfehlen, es einfach meiner Meinung nach zu vermeiden. Probieren Sie es aus und sehen Sie, ob es Ihnen gefällt :)

— Rachel

16

Ich habe CaliburnMicro und MVVMLight ausprobiert und bei der Verwendung von Caliburn habe ich wirklich das Gefühl, dass Sie sich wirklich magisch fühlen, wenn Sie die Kontrolle an eine Eigenschaft binden, indem Sie einfach Name = "PropertyName" anstelle von altem Text = "{Bind PropertyName}" verwenden, aber in Ende Caliburn geht weit über Bord, um diese magische Sache zu tun. Wenn etwas schief geht, ist es wirklich schwierig, Fehler zu beheben, und noch schlimmer, sie haben eine Menge Möglichkeiten, eine Sache zu tun.

Aber wenn Sie MVVMLight verwenden, ist es dünn, und wenn Sie es verwenden, stellen Sie wahrscheinlich fest, dass es fast 100% Ihrem MVVM-Framework entspricht, mit einigen darin enthaltenen Funktionen.

Ich weiß, dass dies Ihre Frage "Wie verwende ich Framework NICHT?" Nicht beantwortet, aber ehrlich gesagt kann ich Ihnen nicht empfehlen, diesen Weg zu gehen, weil es einfach falsch ist einer zuerst.

— kirie
quelle

Denken Sie dann, dass ich zumindest versuchen sollte, MVVMLight als eine Art "Heilmittel" gegen "Caliburn.Micro-Desorientierung" zu verwenden? Ich würde es mir sicher ansehen, wenn das der Fall ist.

— Heltonbiker

@heltonbiker Auf jeden Fall probieren. Es ist so viel einfacher, sollte Ihnen zumindest einen guten Einstieg in MVVM Framework ermöglichen.

— kirie

Ich bin damit einverstanden, dass viel zu viel Magie vor sich geht. Ich gehe davon aus, dass ich von einem Wechselstrom- und Montagehintergrund komme. E etwas wird nicht funktionieren, nur um herauszufinden, dass es magisch im Hintergrund ist. Unmöglich zu debuggen und wenn Sie Leistungsprobleme haben, können Sie oft nicht viel dagegen tun.

— rollt

10

Es ist wichtig zu wissen, was MVVM ist. Es handelt sich nicht um eine gemeinsame Funktionalität, die Sie nicht erneut implementieren müssen (Parsen einer JPEG-Datei oder Herstellen einer Verbindung zu einem bestimmten SQL-Datenbankserver), sondern um ein Muster - ein Muster für die Implementierung einer umfangreichen grafischen Benutzeroberfläche. Wenn Ihre Implementierung des Musters einfach und unkompliziert ist, müssen Sie sich meines Erachtens nicht schämen, es statt eines Frameworks zu verwenden.

Tatsächlich glaube ich, dass die ganze Idee von Mustern als Rahmen viel zu weit gegangen ist. Damit etwas ein Muster ist, muss es die allgemeine Form einer Klasse von Lösungen sein. Da dies so ist, ist zu erwarten, dass Muster auf die Systeme zugeschnitten werden müssen, die sie verwenden, und Sie können dies nicht tun, wenn Sie versuchen, ein Muster mit einer Einheitsgröße zu verwenden. Es wäre weitaus konstruktiver, die Musterimplementierung dem Anwendungsdesigner zu überlassen und Bibliotheken bereitzustellen, die die Funktionalität und nicht die Architektur einschließen.

— Michael
quelle

2

Hinzu kommt, dass MVVM, wie es von Microsoft angeboten wird (Out-of-the-Box, WPF), sehr mangelhaft ist. Sehr frustrierend, auch für Programmierer, die sich (und das zu Recht) als erfahrene Entwickler betrachten. Magische Zeichenfolgen, obskure Ausnahmen in der Laufzeit, die meisten grundlegenden Dinge wie das Binden einer Gruppe von Radiobuttons an eine Aufzählung sehen aus wie stackoverflow.com/q/397556/168719 - was können Frameworks tun? Sie müssen entweder diese Komplexität wiederholen oder versuchen, eine wirklich dicke Abstraktion darüber zu liefern

— Konrad Morawski,

2

@ KonradMorawski WPF an sich ist nicht MVVM; Sie können mit WPF Code hinterher schreiben, aber das ist nicht MVVM. Wenn Sie WPF und MVVM ausführen möchten, müssen Sie ein MVVM-Framework verwenden oder selbst implementieren.

— Andy

1

@Andy natürlich, aber man kann mit Sicherheit sagen, dass WPF für MMVM gedacht ist. Ich beziehe mich auf die MVVM-Funktionalität, die in WPF integriert ist. Ich weiß, dass Sie immer noch Code hinter sich lassen können

— Konrad Morawski,

@KonradMorawski Sie können WPF mit MVVM verwenden, und sie haben es mit Blick auf diese Möglichkeit erstellt. In WPF ist jedoch KEINE MVVM-spezifische Funktionalität integriert. Genauso wie Sie MVP mit WinForms verwenden können, aber WinForms bietet nichts spezielles, um dieses Muster zu verwenden, es liegt an Ihnen.

— Andy

3

@Andy, vielleicht streiten wir uns jetzt über Definitionen. Was ich damit meine ist, dass der gesamte "Klebstoff", der MVVM ermöglicht, bereits vorhanden ist - Datenbindungen in XAML DataContextusw.

— Konrad Morawski

7

Meine erste Erfahrung mit WPF war die Verwendung von Caliburn.Micro, daher unterscheidet sich dies wahrscheinlich erheblich von den meisten Entwicklern. Ich habe festgestellt, dass sowohl WPF als auch Caliburn.Micro eine ziemlich steile Lernkurve sind, da sie von WinForms stammen. Nach einigen Erfahrungen mit beiden habe ich festgestellt, dass es mir ein Vergnügen ist, sie als Paar zu verwenden. Derzeit arbeite ich in einer anderen Organisation, in der Caliburn.Micro nicht verwendet wird. Ich stelle jedoch fest, dass es VIELEN doppelten Code gibt, der die Codebasis ziemlich aufgebläht und unnötig komplex macht.

Ich stimme definitiv zu, dass es einige Probleme mit Caliburn.Micro gibt, die das Debuggen erschweren können, aber sobald sie einmal erlebt wurden, sind sie mit viel geringerer Wahrscheinlichkeit wieder schmerzhaft. Die erhöhte Entwicklungsgeschwindigkeit, der sauberere und schlankere Code und das allgemeine Framework, das eine bessere MVVM fördert, sind es für mich mehr als wert.

Caliburn.Micro macht auch Standard-WPF nicht ungültig - es baut nur darauf auf, was bedeutet, dass Sie weiterhin WPF-Funktionen verwenden können, wenn Sie möchten, und Caliburn für ein paar Teile verwenden können, wenn Sie möchten. Dies ist in etwa so, wie TypeScript und JavaScript in meinem Kopf zusammen existieren.

Ich würde Caliburn.Micro definitiv in jedem neuen WPF-Projekt verwenden, an dem ich in Zukunft arbeite, wenn ich die Gelegenheit dazu bekomme.

— Ross
quelle

3

Danke für deine Antwort. Zwei Jahre später fand ich es viel einfacher, diese Frameworks zu "akzeptieren", nachdem ich das Konzept der Dependency Injection Containers verstanden hatte, das ich aus Mark Seemans "DI in .NET" -Buch gelernt hatte.

— Heltonbiker

1

Wer hier aus Frustration mit Caliburn.Micro ankommt, sollte sich dieses Framework ansehen : Stylet

Es ist von Caliburn.Micro inspiriert, mit der Ausnahme, dass es einen Großteil der Magie beseitigt, die Sie über das, was passiert, desorientiert macht. Darüber hinaus ist die Dokumentation in einer viel einfacheren Sprache verfasst, ohne dass Sie den technischen Jargon durchgehen möchten. Viel besser für Anfänger.

Stylet verfolgt außerdem einen ViewModel-First-Ansatz. Caliburn.Micro und viele andere Frameworks verfolgen einen View-First-Ansatz, der mit einigen umständlichen Problemen einhergeht. Wenn Sie bereits sehr gut mit SOLID-Prinzipien und gemustertem Code vertraut sind, werden Sie einen ViewModel-First-Ansatz wahrscheinlich natürlicher finden, da er die Perspektive einnimmt, dass Ihre Logik das System steuern sollte - nicht die Sicht.

— JamesHoux
quelle