Eine WinForms-Anwendung nach WPF transformieren

Hallo,

gibt es einen Trick wie ich eine WinForms-Anwendung in eine WPF-Anwendung umwandeln kann, oder muss ich alles neu schreiben?

Die Designer-Datei von WinForms ist natürlich in WPF nicht enthalten, dafür gibt es hier den Xaml-Code. Müsste also neu angelegt werdcen.

Kann ich denn zumindestens einen Teil der Geschäftslogik 1 zu 1 übernehmen oder kommt es auch hier zu Fehlermeldungen?

Hallo,

wie viel Code Du fehlerfrei übernehmen kannst, hängt ganz davon ab, wie sauber in der Forms-Anwendung die Schichten getrennt sind.
Wenn die Schichtentrennung optimal umgesetzt ist, musst Du nur das UI neu schreiben.
Wenn sich allerdings irgendwelcher UI-Kram nach unten durchzieht oder Logik (die nicht reine UI-Logik ist) in der UI untergebracht ist, wird es eben aufwändiger.

Gruß, MarsStein

Mit Schichten meinst Du sicherlich Geschäftslogik - Design - Controller.

Kann ich denn z.B. sämtliche Methodenaufrufe von WinForms so übernehmen wie sie sind?

Aber ich denke die Klassenbibliothek müsste doch die gleiche sein.

Den Timer von WinForms gibt es z.B. nicht mehr in WPF, als Komponente.

Hallo,

Kann ich denn z.B. sämtliche Methodenaufrufe von WinForms so übernehmen wie sie sind?

Kommt darauf an was Du damit meinst - aber vermutlich eher nicht.
Wenn Deine Anwendung eine saubere Schichtentrennung hat, ist das unter Winforms normalerweise mit MVC oder MVP umgesetzt. Dann kannst Du die Models und Businesslogik 1:1 übernehmen.
Was neu gemacht werden muss, sind auf jeden Fall die Views, die werden in WPF mit XAML umgesetzt. Und daran bindet man dann ViewModels, und nennt das ganze dann MVVM.
Das bedeutet, dass auch eventuelle Controller bzw. Presenter nicht mehr richtig passen werden. Was dort implementiert ist und mit der Businessschicht kommuniziert, sollte dann entsprechend MVVM auch in den ViewModels umgesetzt werden.

Schau Dir dazu auch entsrprechnende Tutorials und die Artikel [Artikel] Drei-Schichten-Architektur sowie [Artikel] MVVM und DataBinding an.

Den Timer von WinForms gibt es z.B. nicht mehr in WPF, als Komponente.

Richtig. Wenn Du einen solchen Timer in einer tieferen Schicht benutzt, ist das im Prinzip schon ein Designfehler.
In WPF gibt es den DispatcherTimer, der funktioniert ähnlich - sollte aber entsprechend auch nur auf der obersten Ebene verwendet werden. Es gibt aber für tiefere Schichten auch Time, die von der UI-Technologie unabhängig sind, z.B. System.Threading.Timer und System.Timers.Timer.

Ich würde Dir persönlich empfehlen, Dich erst mal ein wenig in WPF/MVVM einzuarbeiten, bevor Du an die Portierung eines bestehenden Projektes gehst, bis Du Dir ein gutes Grundverständnis der Technologie erarbeitet hast.

Gruß, MarsStein

Danke soweit!

Ein Grundverständnis ist bei mir vorhanden, sowohl was WinForms angeht als auch WPF.

Ich verstehe das jetzt so:

Grundsätzlich ist eine Portierung möglich!
Je sauberer in WinForms programmiert wurde(MVC), desto fehlerfreier gelingt die Portierung.

Die Frage, die im Raum stehen bleibt ist:
Rechtfertigen die Vorteile den Aufwand?

WinForms ist auf dem absteigenden Ast und wird von Microsoft nicht weiter verfolgt.
Die Frage nach einer Umstellung wird sich also früher oder später stellen.

Rechtfertigen die Vorteile den Aufwand?

Das kannst nur Du Evaluieren.

WinForms ist auf dem absteigenden Ast und wird von Microsoft nicht weiter verfolgt.

WPF auch nicht. WPF ist genauso Feature Complete wie Windows Forms.

Die WPF Features wie High DPI und Co sind ja auch mittlerweile in Windows Forms verfügbar.
Die Evaluierung kann Dir keiner hier abnehmen.

WPF lagert die ganze Präsentationschicht auf die Grafikarte aus, dadurch ergeben sich schnellere Programme.

Ich werde das ganze mal einer Evolution unterziehen und dann schauen wir weiter.

WPF lagert die ganze Präsentationschicht auf die Grafikarte aus, dadurch ergeben sich schnellere Programme.

Das ist so nicht 100% richtig - ehrlich gesagt nicht mal im Ansatz 😉

WPF verwendet DirectX - und das KANN Zugriff auf die Grafikkarte bedeuten, MUSS aber nicht. Kommt auf die Direct X Version an. Es gibt eine Software- und eine Hardware Pipeline.

Die gesamte Software-Rendering von WPF basiert auf SSE und ist damit CPU-Arbeit.
Und Software Rendering kann schneller sein - je nachdem, was man anzeigt.

Die Power von GPU und WPF merkst Du daher nicht bei einfachen Forms-Anwendungen, sondern dann wenn Du Shader und Texturen hast.

Wenn Du an die Sache gehst mit "unsere Eingabemaske mit 7 Eingabefeldern wird viel viel schneller sein, weil wir WPF verwenden" - dann wirst Du sehr wahrscheinlich sehr enttäuscht von sein 😉

Aha.
Naja, wieder was dazugelernt.

WPF kann schneller sein , muss aber nicht. Nicht zwangsläufig.

Klar, es kommt ja auch auf die jeweilige Hardware an.
Bei einer schlechten Grafikkarte ergibt sich auch kein Geschwindigkeitsvorteil.

Offen gesagt ich habe es auch nie nachgemessen.

Evtl. reicht es auch einfach aus die WinForms-Anwendung performanter zu machen. 😁

In den wenigsten realen Fällen ist das Performance-Problem die UI-Technologie - sondern der Code dahinter.

Hallo,

In den wenigsten realen Fällen ist das Performance-Problem die UI-Technologie - sondern der Code dahinter. Ja, das mein ich auch.
Es sei denn es ist schlecht programmiert, z.B. können gerade im Bereich WinForms völlig mit Controls überladene Fenster oder nicht freigegebene Objekte aus System.Drawing (Pens, Brushes, Fonts etc. - dahinter liegen unverwaltete GDI+-Objekte, deshalb unbedingt alle selbst erzeugten disposen!) schon zu Problemen mit der Performance führen.
Evtl. reicht es auch einfach aus die WinForms-Anwendung performanter zu machen. Wenn Du rausfinden willst, wo's wirklich hängt, dann schau mal mit nem Performance-Profiler. Da siehst Du genau wieviel Zeit wo verbraucht wird.

Gruß, MarsStein