Laden...

Zukunft von WPF, WinForms und Java

Erstellt von wickedcsharper vor 11 Jahren Letzter Beitrag vor 11 Jahren 9.569 Views
Thema geschlossen
wickedcsharper Themenstarter:in
160 Beiträge seit 2008
vor 11 Jahren
Zukunft von WPF, WinForms und Java

Hallöle,

wir haben mitte 2012. Wollte mal hören, wie es mit der Zukunft von WPF aktuell so aussieht. Kommt das rundum zum Einsatz - eventuell bei euch in den Firmen. Es gibt zwar schon ältere Threads, aber da galt WPF noch als Hype. Wie sieht es aktuell aus ?

Mal provokant:
Meine Meinung: WPF ist vom Ansatz her nicht wirklich durchdacht. Trennung der Logik vom Design in allen Ehren - aber welche Firma stellt tatsächlich einen Designer für die Oberflächen ein? Dazu noch diese Expression Blend als teure Zugabe und die "hohe" Lernkurve.Das Oberflächendesign bleibt doch nach wie vor beim Programmierer - und der darf sich jetzt durch XAML Code wuseln.

Bin mich seit 3 Jahren am Einarbeiten - komme aber irgendwie nicht ans Ziel - kennt ihr das?Hab einfach keine Zeit mir wieder 1000 Seiten Literatur durchzulesen und zu verinnerlichen. Mit dem Lesen alleine ist es ja nicht getan. Habs fast aufgegeben und habe mich jetzt sogar mal in der Java Ecke umgesehen - und was finde ich:

XDEV3 eine super RAD IDE für Java ! Zu vergleichen mit der Visual Studio IDE.
Bisher gabs ja soweit ich rausfand kaum oder gar keine RAD Umgebung für Java. Die meisten haben irgendwie mit dem Eclipse gearbeitet - also auf Editor Basis.
Aber mit XDEV3 hätte man eine RAD Umgebung mit JAVA also ähnlich Grundlage wie C# unter WinForms nur halt eben wirklich plattformunabhängig. Und: wesentlich leichtgewichtiger !

Also wie gehts weiter - was glaubt ihr?
Zukunft WinForms weiterhin oder WPF oder Java oder zeichnen sich schon ganz neue Techniken ab.

„Wenn man eine Katze auseinandernehmen will, um zu sehen, wie sie funktioniert, hat man als erstes eine nicht funktionierende Katze in den Händen.“

P
219 Beiträge seit 2008
vor 11 Jahren

Ich bin nur Hobbyprogrammierer, finde das Konzept von WPF eigentlich ziemlich super, die Oberfläche mit XAML zu beschreiben gefällt mir sehr gut. Mit WPF kann man richtig schicke Anwendungen kreiieren, was mit WinForms nur über Umwege oder einfach mal überhaupt nicht möglich ist. Was mich jedoch an der WPF stört ist, dass Microsoft viel zu wenige Steuerelemente standardmäßig bereitstellt. Sobald es nur ein wenig spezieller wird muss man sich sofort selber was zusammenbasteln oder was von Drittanbietern nehmen (was dann u.U. sogar noch kostenpflichtig ist). Meiner Meinung nach sollte es da ne immense Anzahl geben die erstmal alles abdeckt und wenn man dann noch was spezielles braucht kann mans sich auch aus den schon vorhandenen zusammenbasteln.

Ich wüsste auch gerne mal wies mit WPF wohl weitergehen wird oder ob man sich da lieber nach Alternativen umschauen sollte bevor man sich da mit ner aussterbenden Technologie beschäftigt und damit seine Zeit verschwendet.

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo wickedcsharper,

WPF ist vom Ansatz her nicht wirklich durchdacht.

WPF ist zumindest durchdachter, als diese Technologie wegen der Möglichkeit Designer einzusetzen (ev. mit speziellen Tools wie Expression Blend) abzuwerten 😉.

Ob die Lernkurve höher als bei anderen Technologien ist, wage ich nicht zu behaupten. Es kommt hier sehr auf das Individuum und den Hintergrund der bisherigen Tätigkeit an.
Wenn man WinForms korrekt entwerfen will ist die Lernkurve auch hoch. Bei WPF wird man fast gezwungen korrekt zu arbeiten (hier mal rein bezogen auf das Layout) und ich empfinde WPF intuitiver als WinForms od. ASP.net.
Auch wenn jemand Erfahrung in HTML-basierten Sprachen hat, so kann ich mir gut vorstellen dass die Lernkurve in WPF (v.a. in XAML) nicht sehr steil sein wird.

Designer setzten wir keinen ein, da es uns nichts bringt. Außerdem ist ein Designer für eine "Standardoberfläche" wohl nicht nötig, sondern nur dann, wenn eine neue ausgefallen Oberfläche entworfen werden soll und das ist i.d.R. bei Geschäftsanwendungen nicht der Fall.

WPF wird verwendet, da es im Vergleich zu WinForms (dem "direkten .net-Konkurrenten bei Desktop-Awendungen) einige Vorteile hat - diese wurden aber im Forum, im WWW schon so oft durchgekaut, dass ich sie hier nicht alle wiederhole, sondern nur den Bindungsmechanismus erwähne.

Also wie gehts weiter - was glaubt ihr?

So wie bisher auch. WinForms wird weiter existieren, genauso wie WPF auch. Ich glaube aber dass zukünftig das Verhältnis WinForms/WPF zu Gunsten von WPF verschieben wird.

ganz neue Techniken ab.

Auf dem Windows-Gebiet wird es interessant sein, wie sich WinRT verhält.
Für Geschäftsanwendungen zeifle ich eher daran, dass sich WinRT durchsetzt, aber für "Gadgets" und "Apps" wird sich WinRT wohl etablieren (auch weil es MS so will).

Hallo PoWl,

Meiner Meinung nach sollte es da ne immense Anzahl geben die erstmal alles abdeckt

  1. Was ist "alles"? Das wird wohl nie möglich sein (außer nach t -> inf)
  2. WPF wird (so wie fast jedes andere Framework, etc.) auch nach YAGNI und/oder KISS entwickelt, daher gibt es auch außerplanmäßige Toolkit, die hier einspringen.

Hallo zusammen,

auch wenns verlockend sein mag, sollten wir nicht Diskussion die es schon gab (wörtlich) wiederholen. Klar seit den damaligen Diskussionen ist einige Zeit vergangen und daher ist es ganz legitim nach dem Status Quo zu fragen und darüber zu diskutieren. Aber bitte beachtet, dass wir hier keine "WinForms vs. WPF vs. Java Diskussion" führen wollen.
Siehe u.a. auch Zukunft von WPF?

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

6.862 Beiträge seit 2003
vor 11 Jahren

Hallo,

Meine Meinung: WPF ist vom Ansatz her nicht wirklich durchdacht.

Da muss ich gfoidl uneingeschränkt recht geben.

WPF ist wesentlich durchdachter als die meisten anderen GUI Frameworks.
Gerade wenn man z.B: so eine Grundaufgabe wie Layouting anschaut, sieht man die großen Stärken von WPF. Es ist trivial dynamische Layouts zu gestalten, die den Platz den sie bekommen korrekt ausnutzen und auch vollkommen korrekt auf Gegebenheiten wie unterschiedliche DPI der Anzeige Geräte reagieren. Daran scheitern sonst schon fast alle anderen GUI Technologien unter Windows. Und das ganze ist auch noch logisch durchdacht. Wenn man sich mal anschaut wie z.B. ein Control innerhalb eines Containers positioniert wird, dann sieht man z.B. das Windows Forms im Vergleich vollkommen unlogisch ist. Man hat in WPF ein Control und je nach Container setzt man entsprechende attached Properties - bei Canvas Top/Left/Bottom/Right oder beim Grid Row/Column.

In Windows Forms hat das Control selber entsprechende Properties für jeden möglichen in Frage kommenden Container. Es hat immer nen Dock Property und immer Top/Left etc. - wozu? Es kann doch nur einen Container als Parent haben, wieso brauch ich noch alle anderen Eigenschaften für die anderen Container. Um beim TableLayoutPanel auf einmal muss man doch wieder Methodes des Panels benutzen um die Position eines Controls zu bestimmen und nicht mehr die Eigenschaften eines Controls.

Gerade im Vergleich zu Windows Forms, welches ja auch viele Einschränkungen der zugrundeliegenden WinApi mitschleppt, hat MS viel gelernt und in WPF besser umgesetzt.

Trennung der Logik vom Design in allen Ehren - aber welche Firma stellt tatsächlich einen Designer für die Oberflächen ein?

Die Frage mag berechtigt sein, aber selbst wenn man die Trennung nicht in Personalien widerspiegelt, so bieten doch die vorgesehenen Möglichkeiten auch für den alleinigen Bearbeiter viel bessere Möglichkeiten das Programm ordentlich zu strukturieren. WPF hat fantastische DataBinding Möglichkeiten und erlaubt es Code komplett von der GUI zu trennen. Sowas geht mit Windows Forms in der Praxis fast gar nicht da das DataBinding nicht so ausgeprägt ist.

Zu RAD: ich bin kein Freund davon, wenn Leute nicht verstehen was sie machen. Richtig eingesetzt ist das ein gutes Hilfsmittel produktiver zu sein, aber gerade auch so wie du es schreibt, klingts wie GUI zusammenklicken ohne Gedanken um die Grundlagen zu verschwenden. Da ist es vollkommen egal welche Technologie man verwendet - was rauskommt nutzt die Möglichkeiten der Technologie nur im geringen Maße.

Bin mich seit 3 Jahren am Einarbeiten So kompliziert ist WPF auch nicht 😉 Klar ist der Einstieg recht schwer, aber hauptsächlich weil man sich von bekannten Komzepten verabschieden muss. Dann ist grad durch die viel logischere Arbeitsweise von WPF vieles auch einfacher. Ich sehs immer wieder wie ein Kollege von mir versucht WPF zu benutzen wie die ihm bisher bekannten GUI Technologien und gnadenlos scheitert und seine Konstrukte atemberaubend kompliziert werden. Eine Lösung die nach den WPF Prinzipien arbeitet war dagegen dann trivial umgesetzt.

Also wie gehts weiter - was glaubt ihr?

gfoidl hat ja WinRT schon erwähnt, damit einhergehend kann man glaube ich, ohne große Wahrsagerfähigkeiten haben zu müssen, sagen - WPF zu lernen ist mehr als sinnvoll. WPF ist zwar in Zukunft unter Windows 8 auf Deskopanwendungen begrenzt und wie die in zukünftigen Windows Versionen dann aussehen steht in den Sternen, aber WinRT (die man ja ohne schlechtes Gewissen als unmanaged .Net Variante bezeichnen kann) nutzt ebenfalls XAML als Oberflächenbeschreibung. Es kommen zum Großteil die gleichen Konzepte zur Anwendung wie jetzt schon in WPF und Silverlight welche ja auch XAML nutzen. Wenn dir WPF konzeptionell Probleme bereitet, wirds mit WinRT und XAML in Zukunft genauso gehen.

Kommt das rundum zum Einsatz - eventuell bei euch in den Firmen. Wir in der Firma nutzen WPF um für unseren Kunden Simulationen von verschiedenen Bedienkonzepten für ihre Produkte zu simulieren. Viel genauer darf ich das leider nicht schreiben, aber die Anforderungen an die Simulation sind extrem komplex. Es geht nicht nur um irgendwelche Darstellung von Informationen, sondern es geht um völlig neuartige Möglichkeiten wie die Kunden unseres Kunden in Zukunft die Produkte erleben werden. Und dafür werden mit der Simulation dann auch weltweit Probandentests durchgeführt um die Bedienkonzepte in verschiedenen Märkten zu testen und nach psychologischen Gesichtspunkten zu bewerten und da ist es immens wichtig das die Simulation immer genau das macht was es soll da sonst der ganze Test hinüber wird und keine Aussagekraft möglich ist.
WPF ist dafür prädestiniert da es einerseits die ganzen Möglichkeiten bietet wie z.B. auch hardwarebeschleunigte GUI die es enorm erleichtern sehr komplexe grafische Darstellungen zu entwerfen, andererseits aber natürlich auch den .Net Unterbau bietet der uns die möglichkeit gibt unmanaged Code anzusprechen um z.B. neue Hardwarebedienelemente einzubinden zur Steuerung der Simulation.

EDIT: Natürlich ist auch in WPF nicht alles Gold was glänzt, aber ich persönlich halte es für das fähigste UI Framework unter Windows.

Baka wa shinanakya naoranai.

Mein XING Profil.

C
1.214 Beiträge seit 2006
vor 11 Jahren

Ich arbeite hauptberuflich als C++ Entwickler und muss sagen, dass ich einfach froh bin, mit sowas nichts zu tun zu haben 😃 Wir haben eine riesige, komplexe Software, wo GUIs eine sehr untergeordnete Rolle spielen. Für mich ist die GUI sowieso etwas nebensächliches, was nichts mit dem Kern, dem eigentlich interessanten, zu tun hat. Das ist etwas, was irgendwie lästig ist, nebenbei erledigt wird (aber dann auch wieder möglichst gut, weil hingepfuschte GUIs kann ich widerum nicht ausstehen) und wo ich gar nicht so viel Wert auf irgendwelchen krassen Technologien legen will. So betrachtet wäre mir WPF zu viel Aufwand zum reindenken.
Andererseits mach ich privat noch C# und ab und zu nehm ich da WPF. Je nachdem, was ich machen will und wieviel Aufwand mir das Wert ist. Wenn ich ein kleines schickes Tool schreiben will, das modern rüberkommt oder so, nehm ich eher WPF. Wenn es mir um die Idee an sich geht und nicht um deren Verpackung, nehm ich Winforms, damit bin ich wesentlich schneller.
Beim Einarbeitungsaufwand würde ich auch sagen, das kommt drauf an, wie weit man gehen will. Fand ich an sich jetzt nicht sooo hoch, die Grundkonzepte sind schon intuitiv und schnell zu lernen. Wenn man etwas in die Tiefe geht und sich überlegt "wie ist denn das in WPF gedacht?", dann kann man ab und zu auch eine Weile brauchen, bis man das rausfindet. Da muss ich auch sagen, und da bin ich wohl anderer Meinung, als die meisten hier, dass ich WPF nicht so mega toll durchdacht finde. Das ist zwar durchdachter, als die anderen Frameworks, aber es zwingt eben auch, "sauber" und "richtig" zu arbeiten. Richtig nach dem WPF Konzept, was ich nicht unbedingt immer gut finden muss. Bei den anderen Frameworks fühle ich mich meist freier. Und da mich GUIs meist eh nicht interessieren, will ich mir von einem GUI Framework auch nicht zu viel vorschreiben lassen.
Zurück zum Einarbeitungsaufwand. Ich hatte sonst hauptsächlich mit Delphi (VCL), MFC, Winforms, Qt zu tun. Da ist WPF doch ein bisschen anders. Es ist nicht unintuitiv, und es ist nicht schwer oder unlogisch, aber zumindest für mich ist es ein Problem, dass ich Sachen ziemlich schnell vergesse, weil ich nicht ständig damit zu tun habe, und mich dann wieder reindenken muss. Wenn ich ein halbes Jahr nichts damit zu tun hatte und dann wieder eine WPF Anwendung schreiben will, muss ich doch einiges auffrischen.

wickedcsharper Themenstarter:in
160 Beiträge seit 2008
vor 11 Jahren

Hallo zusammen

@talla
Der Vorteil vektorbasierter GUIs und alle grafischen Vorteile mögen auf der Hand liegen. Bei WinForms wie auch anderen UIs ist das halt immer der Nachteil der Anpassung der Anwendung an die Auflösung.Für grafisch anspruchsvolle Anwendungen - vor allem eventuell auch Simulationen mit Grafikbeschleunigung ist das alles sinnvoll.

Für einige Nieschenbereiche mag WPF auch ganz toll sein, aber gängige Probleme der Informatik wie die Verarbeitung großer Datenmengen, technische/mathematische oder systemnahe Fragestellungen und Probleme werden mit WPF schlichtweg nicht gelöst.

Warum also zusätzlich sich mit WPF, WCF, Silverlight, Expression Blend , XAML belasten, wenn dadurch ausser dem "Erlebniswert" einer Anwendung nichts gewonnen wird.
Und das ist es ja, was Microsoft eigentlich erreichen will. Zukünftige Anwendungen sollen zum Erlebnis werden und daher der ganze Gimmiks Firlefans und 3D Aufwand.

Ich finde Microsoft schafft keine intuitiv zu bedienende Entwicklungsumgebung, die einem Informatiker den nötigen Freiraum schafft, sich mit den eigentlichen Problemen aus BWL, Mathematik, Werbung/Marketing, Medizin, Forschung zu beschäftigen, die es mit Hilfe der Programmierung zu lösen gilt.

Stattdessen wird die Programmierumgebung/IDE/Technik zunehmend zum Problem des Informatikers. Wir müssen uns solange mit WPF, WCF, Sharepoint und andern tollen Techniken rumschlagen, bis wir für die Lösung des eigentlich "zu lösenden Problems" keine Zeit mehr haben.

Wer von Euch kann denn behaupten, dass er C#, WPF, WCF, Sharepoint und Asp beherrscht und zusätzlich in der Lage ist, ein kaufmännisches oder mathematisches Problem zu lösen ?

Was ist denn ein Programmierer wert, der all die Techniken beherrscht, aber sonst von Tuten und Blasen keine Ahnung hat. Soll der eine wissenschaftliche oder eine betriebswirtschaftliche sinnvolle Anwendung entwickeln?

Es ist eben nicht mal WPF was ich hinterfrage, sondern die unangemessen hohe Anforderung an einen C# Entwickler. 😉

„Wenn man eine Katze auseinandernehmen will, um zu sehen, wie sie funktioniert, hat man als erstes eine nicht funktionierende Katze in den Händen.“

925 Beiträge seit 2004
vor 11 Jahren

Der Vorteil vektorbasierter GUIs und alle grafischen Vorteile mögen auf der Hand liegen. Bei WinForms wie auch anderen UIs ist das halt immer der Nachteil der Anpassung der Anwendung an die Auflösung.Für grafisch anspruchsvolle Anwendungen - vor allem eventuell auch Simulationen mit Grafikbeschleunigung ist das alles sinnvoll.

Für einige Nieschenbereiche mag WPF auch ganz toll sein, aber gängige Probleme der Informatik wie die Verarbeitung großer Datenmengen, technische/mathematische oder systemnahe Fragestellungen und Probleme werden mit WPF schlichtweg nicht gelöst.

Dafür ist WPF auch nicht unmittelbar vorgesehen. Es ist ein Konzept für GUIs, hat nichts mit systemnahen Fragestellungen zu tun. Die erledigt man im CodeBehind, wenn's nötig ist. Ebenso das Verarbeiten großer Datenmengen. Die DARSTELLUNG großer Datenmengen beherrscht WPF sehr wohl.

Warum also zusätzlich sich mit WPF, WCF, Silverlight, Expression Blend , XAML belasten, wenn dadurch ausser dem "Erlebniswert" einer Anwendung nichts gewonnen wird.
Und das ist es ja, was Microsoft eigentlich erreichen will. Zukünftige Anwendungen sollen zum Erlebnis werden und daher der ganze Gimmiks Firlefans und 3D Aufwand.

Warum sich zusätzlich mit der händischen Verknüpfung von GUI und Anwendungsschicht rumärgern, wenn es die sehr einfache Datenbindung von WPF wunderbar erledigt? Warum sich mti Netzwerkprotokollen und Sicherheitssystemen auseinandersetzen, wenn WCF das alles mitbringt, man es nur einmal sauber konfigurieren muss und dann damit im Code quasi wie mit lokal verfügbaren Daten arbeiten kann? Warum zusätzlich mit Flash rumärgern, wenn man mit Silverlight fast (!) die selben Anwendungen auf Desktop UND im Browser laufen lassen kann?

Ich finde Microsoft schafft keine intuitiv zu bedienende Entwicklungsumgebung, die einem Informatiker den nötigen Freiraum schafft, sich mit den eigentlichen Problemen aus BWL, Mathematik, Werbung/Marketing, Medizin, Forschung zu beschäftigen, die es mit Hilfe der Programmierung zu lösen gilt.

Nochmal, das ist nicht Aufgabe von WPF. Du bringst die explizite, gewollte Trennung von Design und Businesslogik wieder zusammen.

Stattdessen wird die Programmierumgebung/IDE/Technik zunehmend zum Problem des Informatikers. Wir müssen uns solange mit WPF, WCF, Sharepoint und andern tollen Techniken rumschlagen, bis wir für die Lösung des eigentlich "zu lösenden Problems" keine Zeit mehr haben.

War das mit Windows Forms und händischer Programmierung von Datenanbindung und Sicherheitsschicht je besser? Welches Argument spricht für manuelles Verarbeiten und Aktuellhalten von GUI Elementen (OnTextChanged... element.Text = element2.Text; etc.)? Welches Argument spricht für das Arbeiten mit Sockets und select() sowie der manuellen Implementierung von SSL oder anderen Sicherheitskonzepten, wenn WCF und Sharepoint das alles schon mitbringt? Faultheit, sich mit neuen Technologien zu beschäftigen?

Wer von Euch kann denn behaupten, dass er C#, WPF, WCF, Sharepoint und Asp beherrscht und zusätzlich in der Lage ist, ein kaufmännisches oder mathematisches Problem zu lösen ?

Ich beherrsche C#, WPF, WCF. Sharepoint brauchte ich noch nicht und ASP hat mit WPF nichts zu tun. Und nebenbei löse ich problemlos auch mathematische Probleme damit. Die Steuerungssoftware unseres Roboters ist komplett in C#/WPF geschrieben und tut exakt was sie soll, inklusive der Tatsache, dass sie die Position und Orientierung des Roboters auf dem Bildschirm 1:1 wiedergibt.

Was ist denn ein Programmierer wert, der all die Techniken beherrscht, aber sonst von Tuten und Blasen keine Ahnung hat. Soll der eine wissenschaftliche oder eine betriebswirtschaftliche sinnvolle Anwendung entwickeln?

Und was ist ein Entwickler wert, der eingefahren auf einer Schiene ist und heute alles noch von Hand programmiert? Kostet viel zu viel Zeit. Und Lehrgänge auf neue Technologien gibt es in allen Bereichen, auch für WPF etc.

Es ist eben nicht mal WPF was ich hinterfrage, sondern die unangemessen hohe Anforderung an einen C# Entwickler. 😉

... die es quasi nicht gibt, wenn man in der Lage ist, über den Tellerrand hinaus zu schauen und sich daran gewöhnt hat.

Hinweis von herbivore vor 11 Jahren

Spätestens jetzt sind wir wieder bei dem Punkt, den gfoidl schon in deinem ersten Beitrag angesprochen hat: bei der allgemeinen Diskussion der Vor- und Nachteile von WPF. Es ist - außer bei den Hinweisen auf WinRT - kein aktueller Bezug vorhanden. Es wird also nichts gesagt, was nicht schon vorher ausführlich diskutiert wurde. Das kann man aber nachlesen und das müssen wir nicht erneut diskutieren.

Davon abgesehen wird keiner zur Benutzung von WPF gezwungen, so dass jeder, der vor der Wahl zwischen WPF und anderen GUI-Technologien steht und der WPF als zu kompliziert, zu wenig intuitiv o.ä. empfindet, sich für die anderen GUI-Technologien entscheiden kann.

Edit(Talla): Da mich die Frage ob die Technologievielfalt schwierig zu handhaben ist, interessiert, habe ich mal hier Technologievielfalt im Framework - Fluch oder Segen? einen neune Thread dazu aufgemacht.

Thema geschlossen