Windows Forms, WPF oder etwas anderes?

Hallo!

Nun ist es bei uns endgültig die Entscheidung gefallen, zukünftige Entwicklungen (Datenbankapplikationen auf SQL-Basis) hauptsächlich in C# zu machen. Dabei möchten wir auf Technologien setzen, die möglichst ein lange Zukunft haben, wohl wissend, dass keiner eine Kristallkugel hat.

Wir möchten für die Oberflächenentwicklung unserer Datenbankapplikationen selbstverständlich Technologien verwenden, die einerseits die Arbeit mit Daten erleichtern und anderseits auch schön und modern aussehen. Daher dachten wir primär an WPF.

Nun lese ich aber widersprüchliche Berichte über die Zukunft von WPF – einerseits soll diese Technologie aufs Abstellgleis geschoben und durch Standards wie z. B. Javascript/HTML5 usw. ersetzt werden und anderseits soll ihr die Zukunft in der .Net-Welt ganz gehören.

Ich suche seit Tagen immer wieder nach Informationen im Internet, allerdings finde ich nicht wirklich klare Aussagen. Daher habe ich mich entschlossen, hier die Experten zu konsultieren, in der Hoffnung, ihr habt einen viel besseren Einblick, wie es mit WPF zukünftig aussieht und welche Technologien Microsoft für die Zukunft plant.

Sollte das Thema bereits woanders behandelt worden sein, so habe ich es mit der Suchfunktion leider nicht gefunden.

Im Voraus herzlichen Dank!

Bevor WPF so schnell stirbt werdet ihr besagte Anwendung 4-5 mal neu geschrieben haben.
So Diskussionen sind im Forum alle 5-6 Monate...

Ach um noch drauf einzugehen: wie man aller aller spätestens auf der Build 2015 sehen konnte ist WPF >>die<< Referenztechnologie in der Windows-Umgebung.
HTML/JS sind ein Beiwerk und zB auch nur von Windows Store Apps / Universal Apps von Windows unterstützt.

Danke für die schnelle Antwort!

Ich war vor einigen Wochen auf einer Veranstaltung von Microsoft in Stuttgart (VIPP), bei der in erster Linie um Entwicklung für unterschiedliche Produkte auf der Azure-Plattform ging. Dabei wurde ich sehr hellhörig, als des öfteren über neue Wege auf der Basis von Technologien wie Java, HTML5 usw. für die Entwicklung neuer Applikationen gesprochen wurde. Danach gefragt sagten die Vortragenden, dass Microsoft mittlerweile vollkommen offen für Standards sei und sich dagegen nicht sperren will. Wichtig für Microsoft sein in erster Linie die Cloud und darin selbstverständlich die atemberaubend immer größer und mächtiger werdende Azure-Platform. Daher will man auch bei der Entwicklung in erster Linie Standards unterstützen.

So eine Aussage fällt gerade in der Zeit, in der wir uns neu erfinden... und führt schließlich zu Unsicherheiten und Fragen wie in meinem Einganngspost.

Nochmals vielen Dank!

Azure ist eine völlig andere Plattform als ein Desktop-System.
Vergleichbar also wie Apfel und Birne 😉 Und Azure ist nicht nur ein PaaS- sondern eben auch ein SaaS System - und das macht es so riesig.

Aber wenn euch Azure verunsichert dann solltet ihr erst mal definieren ob es eine lokale oder eine Web-basierte Applikation werden soll.
Danach kann man dann eine Entwicklungstechnologie evaluieren...

Was Azure ist, wurde uns in den letzten Monaten richtig bewusst. Ich selbst sehe für die Zukunft keine klare Abgrenzung mehr zwischen lokalen und Web-Anwendungen mehr.

Wir werden zunächst mit der Portierung bzw. Neuentwicklung einer Client-Server-Anwendung starten, die es bereits seit vielen Jahren gibt. Ein Großteil der Geschäftslogik sollte serverseitig abgewickelt werden – so zumindest der Wunsch, was bei der alten Anwendung nicht der Fall ist.

Clientseitig bleiben wir auf der Windowsseite, wobei wir natürlich alle Geräteklassen unterstützen wollen (Windows-PCs, Windows-Tabletts, und Windows-Phones). Zukünftig teilweise auch iOS und Android.

Die ersten Teilprojekte, die auch getrennt von der Hauptanwendung ausgeführt werden können, werden Datenbankanwendungen sein, die lokal auf PCs ausgeführt werden. Zumindest eine der Datenbanken wird nur und ausschließlich über das Internet direkt angesprochen werden. Die Grundlagen dazu sind schon vorhanden (CA-Infrastruktur, SSL-Verschlüsselung usw.), so dass wir mit den Anwendungen starten können. Diese verwenden eine existierende Datenbank mit, die von einer Web-Anwendung zur Verfügung gestellt und benutzt wird.

Mit dieser Ausschweifung möchte ich nur sagen, dass eine klare Trennung nicht möglich ist. Zum jetzigen Stand und für die nächsten 2 bis 3 Jahre wird es sich primär um Windows-Anwendungen handeln.

Nun dafür kommen in erster Linie entweder Windows-Forms oder WPF in Frage. Allerdings werde ich den Eindruck nicht los, dass Microsoft einen Ass aus dem Ärmel zaubert und die eierlegende Wollmichsau rausbringt. Aber da bräuchte man wahrscheinlich die Kristallkugel.

Zum jetzigen Stand tendiere ich zu WPF.

Nochmals Danke!

Das wichtigste in Eurem Fall ist eine gute Architektur, so daß die Darstellung und die Business Logic gut aufgeteilt sind.
Reactive Trader ist ein gutes Beispiel, wie Du ein Projekt dafür richtig strukturieren kannst. Das ist am Anfang natürlich um einiges aufwendiger, aber so bist Du dann zukunftssicher, unabhängig wie sich die Frontend-Technologie entwickelt.

Danke! Unter diesem Aspekt fällt m. E. WF weg. WPF scheint dagegen viel geeigneter zu sein. Angedacht sind mindestens drei Schichten: Datenbank, Server mit Businesslogik und Client. Dabei laufen Überlegungen, den Client eventuell zweischichtig zu realisieren, um die Präsentationsschicht weiter zu abstrahieren.

Nicht immer infach, wenn man seit 25 Jahren hauptsächlich mit was ganz anderem entwickelt hat.

Schönen Feiertag und danke für den Link!

Wenn ich ehrlich bin hört sich das nach einer simplen Client-Server-Infrastruktur an, die man nicht heute entwickelt würde sondern von vor 4-6 Jahren 😉

Microsoft ist hier voll im Trend und geht/lebt den Weg vor: Mobile/Cloud-First.
* Hoch-skalare Datenbankschicht (nSQL-Cluster-Fähigkeit, MongoDB mit ReplicaSet-Fähigkeit)
* Hoch-skalara WebAPI, heutzutage mit OData-Fähigkeit
* OAuth2 mit Client- und UserAuthentication

Hierbei ist meldet sich die Client-Anwendung via OAuth an der WebAPI (über ein OAuth-Token als OAuth-Client) (Desktop-Anwendung, Web-Anwendung, ThirdParty-App) sowie der User(OAuth-User) selbst und dessen Eigenschaften (den OAuth-Claims).
Ein Client würde sich auch niemals direkt bei einer Datenbank anmelden - viel zu unsicher und viel zu hoher Verwaltungsaufwand, schlecht skalierbar; sondern eben über einen Webservice.

Wie der Client dann programmiert ist zBSPA-HTML auf Basis AngularJS oder eben eine WPF-Anwendung, die sich dann an der WebAPI anmeldet: völlig egal und einfach austausch- bzw. erweiterbar.

Reactive Server ist da ein gutes Beispiel.

Vollkommen falsch! Es handelt sich in der Tat um eine C/S-Anwendung, sie ist aber 25 Jahre alt, also nicht 4-6... Sie soll in den nächsten Jahren schrittweise auf .Net überführt werden. Wir können nicht alles über den Haufen werfen und den Kunden sagen, dass die nächsten Updates erst mit der Fertigstellung des neuen Systems in fünf Jahren kommen. Es ist nie alles so einfach, wie man es sich manchmal vorstellt.

Darüber hinaus schrieb ich in meinem vorigen Beitrag, dass neben dem Datenbankserver ein Server mit der Geschäftslogik implementiert wird. Die Clients greifen darüber auf die Datenbank zu – nicht direkt. Direkt, das schrieb ich bereits auch, wird lediglich auf eine Datenbank einer Anwendung eines Drittheratellers zugegriffen. Dafür haben wir bereits eine funktionierende CA-Infrastruktur und der externe Zugriff ist nur und ausschließlich über SSL möglich. Der Datenbankserver lässt von außerhalb keine unverschlüsselten Verbindungen zu. Zudem findet der Anmeldevorgang zusätzlich mithilfe kryptografischer Verfahren innerhalb des SSL-Streams statt. Wenn das unsicher ist, dann fresse ich ein Pferd!

Wir können und werden nicht alles über den Haufen werfen, sondern einen gesunden Mittelweg gehen, der uns einen möglichst sanften übergang ermöglicht. Die Ausgangsfrage bezog sich aber auf die Präsentationsschicht und ich sehe hier WPF vorne, insbesondere nachdem ich vom MS ein Statement vom November letzten Jahres las, in dem die Zukunft von WPF bekräftigt wird. Und sollte man irgendwann doch auf HTML5/Javascript & Co. umsteigen müssen, so muss man die Werkzeuge, aber nicht die Denke ändern – das wäre mit Windows Forms definitiv nicht so.

Es handelt sich in der Tat um eine C/S-Anwendung, sie ist aber 25 Jahre alt, also nicht 4-6... Sie soll in den nächsten Jahren schrittweise auf .Net überführt werden. Wir können nicht alles über den Haufen werfen und den Kunden sagen, dass die nächsten Updates erst mit der Fertigstellung des neuen Systems in fünf Jahren kommen.

Ich weiß nicht wie groß eure Anwendung ist, und ob ihr den Aufwand auch wirklich gut abgeschätzt habt. Ich arbeite in einer Firma (C++, wir haben nichts mit .NET zu tun), die auch an einer Software arbeitet, die seit 20 Jahren entwickelt wird. Vor paar Jahren haben wir auch ein größeres Refactoring gemacht und auf ein moderneres UI Framework umgestellt. Das hat grob zwei Jahre gedauert und auch noch Jahre später finden wir immer wieder etwas, was früher ging und jetzt nicht mehr. Und wir haben auch erst vor wenigen Jahren einen Application Server eingeführt. War auch bei weitem nicht so viel Aufwand eingeplant, wie es dann tatsächlich geworden ist, und es sind dann sehr sehr sehr viele Sachen erst beim Implementieren aufgefallen, die wir nicht berücksichtigt hatten. Dabei rede ich nicht mal von einer kompletten Neuimplementierung in einer neuer Programmiersprache. Also, fünf Jahre wäre jetzt nichts so abwegiges, wie du dir das grad anscheinend denkst. Sollte eigentlich klar sein, wollte dich aber vorsichtshalber doch nochmal warnen.

Verschlüsselung innerhalb des SSL Streams und direkt auf die Datenbank... Verwend doch einfach eine HTTPS Verbinung mit entsprechender Authentifizierung auf einen Webservice 🤔
Und natürlich kann SSL unsicher sein - Stichwort SSL Interception, was bei Firmen üblich ist.... von daher guten Appetit mit dem Pferd.
Aber man muss auch auf dem Boden bleiben.

Wenn Du doch ein Interview von MS gelesen hast, das Deine Frage beantwortet, dann fragen wir uns ehrlich über die Sinnhaftigkeit des Threads.
Aber des Ziel des Threads war eigentlich genau diese Frage und ist letzten Endes aus dem Ruder gekommen;wie bisher jeder Thread mit so einer schwammigen Fragestellung, die niemand zu 100% beantworten kann - daher machen wir nun zu.