Migration von Windows Forms zu WPF ... war es das wert?

Question

Ich habe auch eine Desktop-Anwendung geschrieben in Windows Forms, die eine mittlere Größe ist (ein paar Dutzend Hauptformen von 46 Tabellen in der Datenbank unterstützt). Ich denke über das Umschreiben der Benutzeroberfläche in WPF nach, aber bevor ich dort hinging, war ich neugierig, ob es irgendwelche Kriegsgeschichten über eine solche Konvertierung gab.

Ich verwende LLBLGen, um meine Low-Level-Datenzugriffsobjekte zu generieren, und darüber habe ich eine Business-Logik-Ebene. Die Formulare sind mit den Geschäftslogikobjekten verbunden, obwohl das Hauptformular Caching-Objekte verwendet, um Rundreisen auf den üblicheren Navigationsrouten zu minimieren. Die UI nie spricht direkt mit der Datenbank: immer über die UI -> Business-Logik -> Low-Level -> Datenspeicherpfad.

Ein Steuerelement, das ich stark verwende, ist das TreeView, das als visueller Guide und Short Range Navigation Tool dient. Der Baum wurde stark mit Icons, Highlight-Farben und der Kontrolle über die Portierung gestaltet.

Gibt es eine Geschichte, die mich davon überzeugen könnte, weiterzumachen und zu konvertieren (oder umgekehrt, bis Microsoft unter Windows Forms näher kommt)?

EDIT: Ich wurde in einem Kommentar gefragt, welche Motivation für die Konvertierung ich habe. Ich habe einige Bedenken hinsichtlich der Zukunftssicherheit: Ich habe 500.000 Zeilen Code, die ursprünglich ASP und VBScript waren. Wir haben die Funktionalität im Laufe der Zeit auf ASP.NET und C# portiert, aber nur, wenn wir Änderungen am Code vornehmen. Der Vorteil ist, dass wir die Kosten minimiert haben, der Nachteil ist, dass die Hälfte des Codes ASP und VBScript bleibt. Ich bin besorgt über eine ähnliche Situation, die sich bei Windows Forms-Anwendungen ergibt.

Bin ich besorgt heute über Windows Forms weggehen? Nicht einmal nahe dran ... aber die Anwendung bewegt sich von ASP und VBScript zu ASP.NET und C#, hat neun Jahre Geschichte hinter sich und wird wahrscheinlich in diesem Jahrzehnt nicht ersetzt werden (stattdessen wird es sich einfach weiterentwickeln). Die Desktop-Anwendung ist ebenfalls ein langfristiges Projekt mit langjähriger Geschichte.

Answer 1

WPF ist großartig. Es ist besonders gut für die Erweiterung von Steuerelementen wie TreeView mit Anpassungen. Sie können eine Zeichenfolge als Element in einem TreeControl hinzufügen. Sie können auch ein kleines Fenster mit einem Bild und Text in verschiedenen Schriftarten und Farben hinzufügen. Oder Sie können Schaltflächen hinzufügen oder alles, was Sie möchten. Es hat ein völlig allgemeines Zusammensetzungssystem. Dasselbe gilt für ListBox, ComboBox, Button usw. Alle ihre Inhalte oder untergeordneten Elemente können so einfach wie eine Zeichenfolge oder so komplex wie eine mehrseitige Dokumentanzeige mit Zoom-Schaltflächen sein (wenn Sie möchten).

Aber die einzige Möglichkeit, herauszufinden, ist versuchen, eines Ihrer Formulare zu portieren. Es sollte nicht zu schwer sein, ein WPF-Fenster in Ihrer bestehenden App zu öffnen. Ich begann mit WPF, indem ich neue GUI-Panels erstellte, die in einer C++ Win32-Anwendung gehostet wurden. Schließlich war es so offensichtlich, dass WPF der Weg war, den wir umstellten und die äußere Shell WPF machten, wobei einige alte Dialogboxen noch vom alten C++ - Code implementiert wurden, wo wir sie nicht umschreiben konnten (wahrscheinlich genau was) wird mit Visual Studio 2010 passieren).

Answer 2

Für mich ist die WinForms vs. WPF-Entscheidung einfach - wenn normale Leute sie verwenden, kann die Benutzeroberfläche den Unterschied zwischen einem Gewinner und einem Verlierer ausmachen.

Es ist definitiv eine steile Lernkurve. Aber ich habe NIE mit einer gut aussehenden WPF-Anwendung fertig gemacht und gesagt "Mann, ich hätte WinForms verwenden sollen".

Ich würde sagen, investieren Sie in die Bemühung, Ihre Benutzeroberfläche für Ihre Kunden so gut wie möglich zu machen, also ja zu WPF, wenn das der Fall ist.

Answer 3

WPF hat eine lächerlich große Lernkurve. Es wird sehr wahrscheinlich erforderlich sein, dass Sie viel mehr umschreiben als Sie denken, nur um die Benutzeroberfläche zu ändern. Außerdem sind viele Funktionen, die WPF schöner machen würden, noch nicht implementiert oder in WPF enthalten. Unlike routeNpingme, ich habe schön aussehende WPF-Anwendungen geschrieben und gesagt: "Was für eine Verschwendung von Zeit, ich hätte Windows Forms verwenden und in 70% weniger Zeit fertigstellen sollen".

EDIT: auch, es sei denn Microsoft einen Weg herausfindet, um WPF einfacher zu lernen, ich sehe es überhaupt nicht um die Massen auf den Fang. WPF kann einige sehr coole Dinge tun, aber ein wenig Aufwand, um es zu verstehen, anstatt Zeug über die Mauer zu werfen, wäre ein langer Weg gegangen. Es würde mich nicht im geringsten überraschen, dass Microsoft WPF für etwas fallen lässt, mit dem man in nicht allzu ferner Zukunft leichter arbeiten kann. Ändern Sie Ihre Windows Forms-Anwendung nicht einfach, um sie zu ändern.

Answer 4

Portieren ist eine schwierige Entscheidung.Also nur ein paar Gedanken um dir zu helfen.

WinForms ist in Ordnung, während Sie nach den Regeln arbeiten und alles so beibehalten, wie es ist. Aber selbst das Neuzeichnen eines Rahmens für einige Steuerelemente erfordert komplexe und präzise Arbeit und Fähigkeiten, wie Sie bereits von der Baumanpassung wissen. Die gleichen Aufgaben können in WPF sehr elegant erledigt werden.

Auch die Datenbindung in WPF spart mir viel Zeit. Langfristig denken Sie über Datenbindungsszenarien nach, die in WinForms ohne spezielle Codierung nicht remote möglich sind.

Ich denke nicht einmal WinForms für neue Entwicklung - es gibt keine Entschuldigung für die Anpassung Kosten.

Answer 5

Vorteile:

• Lächerlich einfache Datenbindung (die meiste Zeit)
• Lächerlich einfache Anpassung des Look and Feel

Nachteile:

• Sehr steile Lern Kurve
• Einige offensichtliche Bugs oder Probleme . Ähnlich wie bei .NET 1.0 Windows Forms
• wenig oder gar keine Werkzeugunterstützung

Meiner Meinung nach, WPF wird auf jeden Fall Windows Forms irgendwann ersetzt werden. Aber im Moment sind die Werkzeuge die Hauptsache, die es zurückhält. Ich stimme Dunk nicht zu, dass Microsoft es für etwas anderes fallen lassen wird. Ändern Sie es ja, aber ich denke, es ist hier zu bleiben.

Sollten Sie Ihre Anwendung jetzt für die Verwendung von WPF ändern? Nein. Fühlen Sie sich frei, WPF zu lernen, aber wenn Ihre Anwendung im Moment gut funktioniert, wird WPF Ihnen nichts mehr geben. Es macht einfach das, was in Windows Forms möglich ist.

Answer 6

Ich habe mit der Einführung von WPF-Elementen in meiner WinForms-Anwendung begonnen und war bisher sehr erfolgreich.

Die Hauptkomponente der Anwendung ist ein Raster-Steuerelement, und ich habe noch nicht gefunden, die Text-Rendering von WPF scharf genug, um eine Tabelle mit wichtigen Textdaten zu präsentieren.

Aber die Anwendung hat mehrere zusätzliche Panels, und die Mehrheit von diesen sind mit WPF implementiert.Also, ich bin für eine Mischung aus WinForms und WPF über die ElementHost Kontrolle.

Ich habe die Flexibilität von WPF gefunden, um eine viel attraktivere und brauchbare Benutzeroberfläche zu ermöglichen, und meine Benutzer scheinen damit sehr zufrieden zu sein. In meinem Fall war es auch politisch einfacher, WPF ein Panel gleichzeitig vorzustellen.

Answer 7

WPF's Hauptwert ist für mich in der Bindung, nicht in der Kühler UI. Die schlechteste WPF, die ich jemals gesehen habe, ist, wenn Leute WPF verwenden, nur weil es neuer ist, und die ganze Arbeit in den Code-Behind steckt, einschließlich der Verwendung von Binding. Was Sie bekommen, ist WinForms Datenmanagement. Seien Sie also sicher, dass Sie die wundervolle Bindung verwenden, wenn Sie WPF machen.

Ich würde die Business-Logik des OPs auf eine Business-Schicht portieren, um Wartung und Konvertierung zu vereinfachen. Ich würde die WinForms überhaupt nicht nach Xaml portieren, wenn keine neue Xaml-Funktionalität benötigt würde, und vorzugsweise nicht bevor die Funktionalität portiert wurde.