C# WinForms oder WPF in Hinsicht auf MAUI

[Wichtelherbert]

Kurze Frage an die erfahrenen Programmierer.

Ausgangssituation: C# Programm mit GUI

In Hinsicht auf "MAUI" oder andere Plattformübergreifende Frameworks welches wäre der elegantere Weg?
WinForms oder WPF nutzen?

Bisher dachte ich immer eine Anwendung mit WPF geschrieben, kann ich später problemlos das GUI austauschen und fertig. Allerdings habe ich jetzt einiges gelesen und da sieht es doch gar nicht so einfach aus.

Also könnte ich auch WinForms nutzen (dies hatten wir schon in der Ausbildung) und muss am Ende sowieso alles neu schreiben, wenn ich auf MAUI oder Konsorten umsteigen wollte?

 

[tollertyp]

Wie einfach/schwer es ist, die UI-Technologie zu ersetzen, hängt maßgeblich von der Qualität deines Codes ab. Komplett ohne Aufwand wird es nie gehen. So lange aber kein Business-Code im UI-Code verwurschtelt ist, kann es halt dennoch gut gehen.

Wenn du "alles" neu schreiben musst, musst du die Architektur hinterfragen.

 

[breedmaster]

Die beiden nehmen sich da nicht viel grundsätzlich. Spezielle Anforderungen oder auch Kompetenz im Team können da weitere Faktoren sein.
Schau dir mal Blazor an. Damit ist man recht flexibel.
Wie tollertyp schon schrieb machst du grundsätzlich was falsch, wenn du "alles" neu schreiben musst. Oder meist du nur den UI-Teil?

 

[Wichtelherbert]

Den Code werde ich so weit wie möglich außerhalb der UI schrieben. Das ich hier und da ein wenig anpassen muss ist mir klar.

Aber im Allgemeinen interessiert es mich ob WPF da vlt. ein wenig Vorteile im späteren Verlauf bringt, da man ja die UI durch XAML besser vom eigentlich Code trennen kann.

 

[tollertyp]

Ich kann nur wiederholen was ich quasi schon schrieb:
Es hängt weniger von der Technologie ab, sondern von der Qualität des Codes.

Du wirst in XAML auch C#-Code haben mit Event-Listenern haben, die nur für WPF genau so funktionieren (aufgrund der Event-Datentypen und Paramtern usw). Wenn in den Klassen, in denn die Event-Listener liegen, auch Business-Code liegt, oder gar im Event-Listener selbst essentielle Programm-Logik, dann hast du da mehr oder weniger die gleichen Aufwände.

Wenn es dir so ungemein wichtig ist, dass dein Programm einfach für verschiedene UI-Technologien anpassbar machen kannst, würde ich persönlich folgendes machen:
a) Strenge Trennung zwischen UI und Business-Code. Idealerweise liegt der Business-Code dann sogar in einem eigenen Projekt, das gar keine UI-Abhängigkeiten hat, damit man gar nicht erst versehentlich irgendwelche Klassen daraus nutzt.
b) Idealerweise setzt du die Software gleich mit zwei verschiedenen UI-Technologien um., um "Anforderungen" verschiedener UI-Technologien gleich zu berücksichtigen.

Selbst a) alleine bedeutet oftmals einen Mehraufwand, der für einfache Projekte gar nicht unbedingt notwendig ist. Die Frage sollte also immer noch bleiben: Wie wahrscheinlich ist es, dass man die UI-Technologie tauschen wird?

 

[Wichtelherbert]

Also spräche absolut nichts gegen WinForms? Würde so weit wie möglich die UI mit der Logik trennen.

Bisher wurde mir immer gesagt, dass WPF moderner sei und man damit es leichter hat am Ende die UI zu wechseln....

 

[tollertyp]

Kannst dir ja hier die Gegenüberstellung anschauen:
https://www.geeksforgeeks.org/difference-between-wpf-and-winforms/

Da gibt es viel wichtigere Argumente als die Frage, ob du die UI mal einfach austauschen kannst. Wie gesagt, mit einer konsequenten und sauberen Architektur kann an das auch bei WinForms erreichen.

Und ein UI-Tausch muss ja Gründe haben, den macht man ja nicht einfach so. Wenn der einzige Vorteil, den WPF für dich bietet, dass du (angeblich) die UI einfacher tauschen kannst, welche Ansprüche hast du denn an eine UI? Welche Vorteile würde eine spätere UI-Technologie denn bringen, was heute noch nicht optimal wäre?
Also wenn WinForms andere Vorteile hätte, würdest du dan WPF bevorzugen, weil du es einfacher ersetzen kannst? Wieso nicht gleich die richtige Technologie verwenden dann?

Und ich habe schon ein Spiel geschrieben, das konnte man gleichzeitig als Desktop-Fenster-Anwendung, in der Kommandozeile und im Browser spielen. Also die selbe Instanz des Spiels.

Was ich halt sagen will: Was du nimmst ist vermutlich jedem hier ziemlich egal, Du musst damit arbeiten. Und du musst wissen, warum du welche Technologie nimmst. Modern alleine ist kein Grund aus meiner Sicht. Aber wenn die Dinge, die die Technologie modern machen, für mich nützlich sind, dann ist es etwas anderes. Wie schwer es ist, die UI-Technologie auszutauschen, liegt so oder so in meiner Verantwortung.

 

[Wichtelherbert]

Habe mir den Link mal angeschaut, danke hierfür.

Derzeit habe ich Befürchtungen, alles mit WinForms zu machen und in nächster Zeit muss ich alles umstellen, da MAUI genutzt werden soll (weil auf Mac und Linux lauffähig).
Daher würd eich gleich auf das Pferd setzen, was mir am Ende mehr bringt.

Gibt es sonst keine Meinungen? Gibt doch sicherlich auch noch andere Entwickler im .NET Universum.

 

[gymfan]

Gibt es sonst keine Meinungen? Gibt doch sicherlich auch noch andere Entwickler im .NET Universum.

Meine ganz persönliche Meinung (überwiegend basierend auf meinen privaten Projekten und einer WPF-Schulung vor einigen Jahren):

• ich mag WPF (oder besser gesagt XAML) nicht
• WinForms würde ich heutzutage nur noch nutzen, wenn die SW nur mit 100% Skalierung genutzt werden soll oder das skalierte Aussehen egal ist.

Rein privat nutze ich weiterhin WinForms, inkl. von mir persönlich (schon vor Jahren, bevor MS das wollte) gebastelten Funktionen zur Skalierung der GUIs auf >100% soweit, wie ich das für meine Programme benötige. Aber außer für größere Programme schreibe ich dabei Code auch gerne mal ganz bewusst direkt in GUI Event-Handler. Hauptsache, es geht einfach, ich habe einen gut funktionierenden Code- und GUI-Editor (also VS) und ich steige auch nach 1-5 Jahren noch durch meínen Code durch.

da MAUI genutzt werden soll (weil auf Mac und Linux lauffähig)

Ist MAUI vorgegeben oder "nur" die Lauffähigkeit auf den anderen Plattformen?

Produktiv würde ich (wenn MAUI denn 2022 mal als angeblich "stabile" Version kommen sollte), erst in 2-3 Jahren drauf setzen. Oder lieber in 4-5 Jahren wenn klar ist, ob MS das bis dahin nicht schon wieder eingestampft hat.

Bisher wurde mir immer gesagt, dass WPF moderner sei und man damit es leichter hat am Ende die UI zu wechseln....

Mit WPF wirst Du quasi gezwungen, Dich an gewisse Design-Pattern (oft MVVM) zu halten, was die Trennung zwischen Business-Code und UI bedingt. Trotzdem musst Du bei einem Wechsel des UI-Toolkits den UI-Teil an das neue Toolkit anpassen.

Und genauso, wie Du für WinForms selbst gebaute Steuerelemente bei einem Wechsel komplett neu schreiben musst, musst Du alles, was Du bei WPF mit XAML programmierst, später an das neue UI-Toolkit anpassen. Daran, dass XAML von MAUI zu 100% kompatible zu XAML aus .NET 4x (oder auch 5) sein wird glaube ich erst, wenn MS das in der Praxis beweist.

MVVM (oder ein anderes Design-Pattern, welches Dir später den Wechsel der UI erleichtert) kannst Du auch mit WinForms realisieren. Je nach eigener Einstellung musst Du Dich nur dazu "zwingen".

 

[Wichtelherbert]

Ist MAUI vorgegeben oder "nur" die Lauffähigkeit auf den anderen Plattformen?

Nein, MAUI ist nicht vorgegeben. Allerdings wüsste ich dann nur noch C++ mit QT welches auf beidem läuft. Xamarin wollte ich nicht nutzen.

 

[tollertyp]

Oder halt Electron (JS/TS und HTML). Qt würde denke ich auch mit Java gehen, falls dir das mehr zusagt als C++.

Hat alles seine Vor- und Nachteile.

 

[gymfan]

Kein Xamarin, kein GTK#, kein Qml.NET (sind beides "nur" Community-Projekte). Blazor oder Electron(.NET) fallen wohl auch aus. Da fällt mir für .NET auch nicht mehr viel ein außer dem blinden Vertrauen darauf, dass MS diesmal (nach der wievielten Verschiebung von MAUI) direkt alles richtig macht und das Projekt nicht zu schnell wieder einstampft.

Persönlich bin ich noch über keine einfache und plattformübergreifende Lösung gestolpert, mit der ich meine (privaten) WinForms .NET Programme konvertieren könnte, um von Windows weg zu kommen. Mal sehen, ob ich bis 2025 den Aufwand treibe oder doch in den sauren Apfel beiße und auf Win 11 umstelle. Ein anderer HW-Apfel wäre mir eigentlich lieber, wenn ich schon meine HW wegschmeißen muss.

Ergänzung (7. November 2021)

da MAUI genutzt werden soll (weil auf Mac und Linux lauffähig).

Nur mal als Hinweis, weil ich gerade darüber gestolpert bin und mir das so nicht mehr klar war:
https://docs.microsoft.com/de-de/dotnet/maui/what-is-maui?WT.mc_id=onedevquestion-c9-dotnet6
also KEIN MAUI/Linux Support direkt von MS.
Was sie hier auch nochmal bestätigen:
https://devblogs.microsoft.com/dotnet/announcing-net-maui-preview-9/

Aber klar, es gibt hier einen ersten Fork/Port dazu, der dann auf GTK# basiert
https://github.com/jsuarezruiz/maui-linux
In weit man sowas (insb. in den ersten Monaten/Jahren) für produktiv genutzte SW einsetzen kann/möchte, hängt wohl extrem von der Branche und dem Einsatzgebiet ab.

 

[Wichtelherbert]

Also werde ich wohl doch zu C++ mit QT greifen müssen. Wenn Linux nicht unterstützt würde, wäre das nicht das Problem. Mac würde mir schon ausreichen, so dass ich alle meine Programme dann da ohne Windows Emulation nutzen kann.