Wie wähle ich, ein Framework (Caliburn.Micro usw.) NICHT in einer bestimmten MVVM-Anwendung zu verwenden?

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 studiert. Tatsache ist: Ich habe Caliburn.Micro dafür nicht verwendet und einige MVVM-Konzepte selbst implementiert (insbesondere nur die ViewModelBase und RoutedCommand Klassen).

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

Ich habe dieser berühmte Blog-Beitrag , dessen Titel besagt, dass “ Wenn Sie MVVM verwenden, dann brauche ein Framework „, das:

“ Der Versuch, so etwas wie MVVM ohne Framework auszuführen, ist ein enormer Arbeitsaufwand. Tonnenweise doppelter Code, Neuerfindung des Rads und Umschulung von Menschen, um anders zu denken .

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

Ich würde der ersten Lesung zustimmen, aber meiner tatsächlichen Erfahrung mit Caliburn.Micro (CM) In meiner tatsächlichen Anwendung ist es ahnungslos und desorientiert. Das heißt, das Framework hat den Prozess überhaupt nicht einfacher gemacht, im Gegenteil. Lesen Sie die sich ständig wiederholenden Beispiele von Rob Eisenberg in der eher (zu) informellen Dokumentation und versuchen Sie, Verwendungsmuster aus den verschlungenen Beispielen abzuleiten. und ihre absolut indirekten Klassen- und Schnittstellenbeziehungen, in denen die Dinge so gestaltet zu sein scheinen, dass sie basierend auf Nebenwirkungen wirken, scheinen menschlich unmöglich, es sei denn, Sie sind ein erfahrenes Genie (entschuldigen Sie die Beschimpfungen, aber ich denke, Sie wissen es was ich meine).

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

Jetzt, da ich überlege, zu meinem hausgemachten MVVM-Framework zurückzukehren – das nur aus einer Handvoll MVVM besteht – Bestimmte Klassen, die ich tatsächlich implementieren möchte – Ich möchte CM zumindest eine Chance geben, falls ich hier etwas verliere oder einfach nur Dinge “ falsch mache “ aus purer Unerfahrenheit und Unwissenheit. Die Frage lautet also:

Es besteht weitverbreiteter Konsens darüber, dass “ Frameworks die Dinge einfacher und natürlicher machen „, aber wenn ich zufällig das Gegenteil erlebe, bedeutet dies, dass ich das Framework nicht verwenden sollte oder dass ich versuche, es falsch zu lernen? Gibt es eine Hinweis, dass ich überhaupt kein Framework verwenden sollte? Oder gibt es eine “ richtige “ Möglichkeit, um herauszufinden, wie CM für die einfache MVVM-Entwicklung verwendet wird?

Kommentare

  • Persönlich wähle ich Elemente aus jedem Framework aus, die für bestimmte Verhaltensweisen verwendet werden sollen, und ignoriere den Rest. Zum Beispiel verwende ich gerne Microsoft PRISM ‚ s EventAggregator für Nachrichten und NotificationObject für a ViewModelBase und MVVM Light ‚ s RelayCommand für Befehle. Wichtig ist, zu ermitteln, welche Probleme das Framework für Sie lösen wird, und nur diese Lösungen zu verwenden. ‚ Sie haben nicht das Gefühl, dass Sie ‚ gezwungen sind, die gesamte Framework-Bibliothek zu verwenden.
  • @Rachel Ich hatte geplant um diesen Ansatz mit Caliburn.Micro zu verwenden, konnte jedoch ‚ keine RelayCommand -Implementierung finden (da es “ bindet “ gemäß Konvention direkt an Methoden, anstatt an ICommand-Eigenschaften zu binden.
  • I ‚ Ich habe das Caliburn-Framework nie verwendet, weil mir ‚ nicht gefallen hat, wie eng es die Ansichten mit der Model / ViewModel-Ebene zu verknüpfen schien.In Ihrem Fall sehe ich ‚ keinen Grund, warum Sie ‚ kein RelayCommand aus einer anderen Bibliothek, wenn die von Caliburn Micro verwendete Bibliothek für Sie nicht funktioniert.
  • @Rachel bezüglich “ wie eng [caliburn] die Ansicht mit dem verbindet MVM-Schicht „, was genau meinst du? Was wäre die “ nicht kalibrierte “ Methode, um diese Ebenen auf eine bessere, MVVM-Weise zu binden? (Ich frage aufrichtig, weil ich ‚ derzeit nicht weiß).
  • Ehrlich gesagt habe ich ‚ Caliburn Micro noch nie 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 über die Code-Behind-Objekte verantwortlich war. Dies ist ein Aspekt, den ich nicht mochte, da ich View-First ‚ nicht mag Entwicklung. Ein weiterer Grund waren die automatischen Bindungen, die davon abhingen, wie Sie XAML-Komponenten benennen, da ich dachte, dass sie die Benutzeroberfläche zu stark mit der Geschäftsschicht verknüpfen. Ich habe jedoch gute Dinge über das Framework gehört und würde nicht empfehlen, es nur meiner Meinung nach zu vermeiden. Probieren Sie es selbst aus und sehen Sie, ob es Ihnen gefällt 🙂

Antwort

Ich habe CaliburnMicro und MVVMLight ausprobiert und wenn ich Caliburn benutze, fühle ich wirklich, was Sie fühlen, sicher, dass es wirklich magisch ist, ein Steuerelement an eine Eigenschaft zu binden, indem Sie einfach Name = “ PropertyName “ anstelle von altem Text = “ {Eigenschaftsname binden} “ aber am Ende geht Caliburn weit über Bord, um diese magische Sache zu tun . Wenn etwas schief geht, ist es sehr schwierig zu debuggen und die Dinge noch schlimmer zu machen. Sie haben viele Möglichkeiten, eine Sache zu tun.

Im Gegensatz dazu ist MVVMLight sehr dünn. Wenn Sie es verwenden, stellen Sie wahrscheinlich fest, dass es fast zu 100% Ihrem MVVM-Framework ähnelt, mit einigen Funktionen.

Ich weiß, dass dies Ihre Frage nicht beantwortet “ Wie man das Framework “ NICHT verwendet, aber ehrlich gesagt kann ich Ihnen nicht empfehlen, diesen Weg zu gehen. Ich denke, Sie sind einfach verloren, weil Sie ein Framework mit vollem Funktionsumfang verwendet haben, anstatt zuerst ein einfaches zu verwenden.

Kommentare

  • Denken Sie also, dass ich zumindest versuchen sollte, MVVMLight als eine Art von “ Heilung “ von “ Caliburn.Micro-Desorientierung „? Ich würde sicherlich einen Blick darauf werfen, wenn dies der Fall ist.
  • @heltonbiker Probieren Sie es auf jeden Fall aus. Es ist so viel einfacher, wenn Sie zumindest einen guten Einstieg in MVVM Framework finden.
  • Ich stimme zu, dass viel zu viel Magie vor sich geht. Ich gehe davon aus, dass ich einen C- und Assembly-Hintergrund habe. E etwas, das ‚ nicht funktioniert, funktioniert nur aufgrund von Magie im Hintergrund. Es ist unmöglich zu debuggen und wenn Sie Leistungsprobleme haben, können Sie oft nicht viel dagegen tun.

Antwort

Es ist wichtig zu erkennen, 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 Auswahl eine reichhaltige GUI zu implementieren. Wenn Ihre Implementierung des Musters einfach und unkompliziert ist, müssen Sie sich meiner Meinung nach nicht schämen, wenn Sie es anstelle eines Frameworks verwenden.

In der Tat glaube ich, dass die gesamte Idee von Mustern als Frameworks vorhanden ist viel zu weit gegangen. 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 einheitliches Muster zu verwenden. Es wäre weitaus konstruktiver, die Musterimplementierung dem Anwendungsdesigner zu überlassen und Bibliotheken bereitzustellen, die die Funktionalität und nicht die Architektur kapseln.

Kommentare

  • Hinzugefügt zu dass MVVM, wie es von Microsoft angeboten wird (out of the box, WPF), sehr fehlt. Sehr frustrierend, selbst 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 wiedergeben oder versuchen, eine wirklich dicke Abstraktion darüber bereitzustellen.
  • @KonradMorawski WPF an sich ist keine MVVM. Sie können mit WPF Code dahinter ausführen, aber das ‚ ist nicht MVVM. Wenn Sie also WPF und MVVM ausführen möchten, müssen Sie ‚ ein MVVM-Framework verwenden oder selbst implementieren.
  • @Andy natürlich, aber es ‚ kann mit Sicherheit sagen, dass WPF für MMVM bestimmt ist.Ich ‚ beziehe mich auf die MVVM-Funktionalität, die in WPF integriert ist. Ich weiß, dass Sie immer noch Code hinter
  • @KonradMorawski ausführen können. Sie können WPF mit MVVM verwenden, und sie haben es unter Berücksichtigung dieser Möglichkeit erstellt, aber es ist KEINE MVVM-spezifische Funktionalität in WPF integriert. Genau wie Sie MVP mit WinForms verwenden können, aber WinForms bietet nichts spezielles, um dieses Muster zu verwenden. Es liegt an Ihnen.
  • @Andy Vielleicht streiten wir uns ‚ darüber Definitionen jetzt. Was ich meine ist, dass alle “ Kleber „, die MVVM ermöglichen, bereits vorhanden sind – Datenbindungen in XAML, DataContext usw.

Antwort

Meine erste Erfahrung mit WPF war die Verwendung von Caliburn. Micro also ist dies wahrscheinlich ganz anders als die meisten Entwickler. Ich habe festgestellt, dass sowohl WPF als auch Caliburn.Micro eine ziemlich steile Lernkurve sind, die von WinForms stammt. Nach einigen Erfahrungen mit beiden habe ich jedoch festgestellt, dass es eine Freude ist, sie als Paar zu verwenden. Derzeit arbeite ich in einer anderen Organisation, in der Caliburn.Micro nicht verwendet wird. Ich finde, dass es VIELEN doppelten Installationscode gibt, der die Codebasis ziemlich aufgebläht und unnötig komplex macht.

Ich stimme definitiv zu, dass es einige Fallstricke gibt mit Caliburn.Micro, was das Debuggen erschweren kann, aber sobald sie einmal erlebt wurden, ist es viel weniger wahrscheinlich, dass sie wieder Schmerzen verursachen. 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 Kleinigkeiten verwenden können, wenn Sie möchten. Dies ähnelt der Koexistenz von TypeScript und JavaScript in meinem Kopf.

Ich würde Caliburn.Micro auf jeden Fall in jedem neuen WPF-Projekt verwenden, an dem ich in Zukunft arbeite, wenn ich die Chance dazu habe.

Kommentare

  • Vielen Dank für Ihre Antwort. Zwei Jahre später fand ich es viel einfacher, “ “ diese Frameworks zu akzeptieren, nachdem ich das Konzept der Abhängigkeitsinjektionscontainer verstanden hatte, das ich aus dem ausgezeichnetes Mark Seeman ‚ s “ DI in .NET “ Buch.

Antwort

Wer frustriert aus Caliburn.Micro hierher kommt, sollte sich dieses Framework ansehen: Stilett

Es ist von Caliburn.Micro inspiriert, außer dass es einen Großteil der Magie entfernt, die Sie desorientiert darüber macht, was passiert. Darüber hinaus ist die Dokumentation in einer viel einfacheren Sprache verfasst, ohne dass Sie den Fachjargon durcharbeiten möchten. Viel besser für Anfänger.

Außerdem verfolgt Stylet einen ViewModel-First-Ansatz. Caliburn.Micro und viele andere Frameworks verfolgen einen View-First-Ansatz, der mit einigen umständlichen Problemen verbunden ist. Wenn Sie bereits sehr gut mit SOLID-Prinzipien und gemustertem Code vertraut sind, ist ein ViewModel-First-Ansatz wahrscheinlich natürlicher, da davon ausgegangen wird, dass Ihre Logik das System steuern sollte – nicht die Ansicht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.