none
Weiß nicht wo ich ansetzen soll ASP.NET / WebForms? RRS feed

  • Frage

  • Hallo Community,

    folgendes Szenario:
    Ich habe eine WinForms Anwendung geschrieben, die auch gut ankommt und genutz wird in unserem Unternehmen.

    Adie Anwendung soll nun auch für externe Mitarbeiter verfügbar sein und soll deshalb in einem Browser, also über's Web, erreich- und bedienbar sein.
    Ich werde einfach nicht fündig.
    Wie kann ich dies umsetzen?
    Klassen und Daten sind vorhanden. Alles ist in C# geschrieben.
    Die Anwendung läuft halt in WinForms.
    Gibt es eine Möglichkeit das Ganze nach WebForms zu portieren ohne nochmal von vorne anzufangen?
    Mit ASP und Webforms habe ich noch keine Erfahrung.
    Welches Forum ist dazu geeignet?
    Schon mal vielen Dank
    Grüße
    Manfred

    Mittwoch, 28. August 2019 08:10

Alle Antworten

  • Eine Winforms-Anwendung lässt sich nicht nach ASP portieren.
    Davon kann man sich i.d.R. komplett verabschieden, da sich hier 2 verschiedene Welten begegnen.

    Windows:
    Alles ist integriert, man kann in Formen beliebig mit Objekten umgehen. Prüfungen/Validierungen können mittels Ereignis direkt verarbeitet werden.

    Web:
    Hier hat man 2 Teile: Server-Funktionalität und den sog. stateless Client. Der Client sendet Anforderungen die vom Server verarbeitet werden und an den Client zurückgesendet werden. Alle Daten eines Geschäftsvorfalles werden z.B. in einer "Bag/Sessionstate" gesammelt bis der finalisierte Zustand erreicht wird.
    Der Serverprozess verarbeitet die Anforderungen der Clients alle im selben Prozess über Threads separiert.
    Dies erfordert auch ein Umdenken was Synchronisation zwischen Objekten angeht damit sich die Clients nicht gegenseitig ins Gehege kommen.
    Noch schlimmer wird es, wenn im Web einfach ein neuer Reiter aufgemacht wird. Hier wird dieselbe Sitzung wieder verwendet, also Aktionen in Fenster 1 bedingen ggf. ebenso Zustandsänderungen in Fenster 2. Auch solche Szenarien gehören beachtet.

    Wichtige Voraussetzung ist auf jeden Fall, dass die Anwendung so in verschiedene Assemblies getrennt sind, dass man die Business-Logik auch ohne den Frontend bedienen kann.
    Ist dies nicht gegeben, wird es erst recht schwierig, dann fängt man auf der grünen Wiese neu an um ein Konzept zu erstellen.

    Am Besten ist es, wenn man sich dann mit Frameworks beschäftigt, die u.U. verschiedene Frontends generieren kann. Dies verlangt aber einen ganz anderen Ansatz.

    Ich verwende z.B. Komponenten von DevExpress, so dass man hier bei eintsprechender Projektierung Forms/WPF oder ASP/Mobil-Anwendungen erstellen kann.

    Ich denke, mit Foren kommst du da nicht wesentlich weiter. Hier sind eher Schulungen angesagt.
    Die gibts natürlich auch im Selbststudium:
    https://docs.microsoft.com/de-de/dotnet/samples-and-tutorials/

    Alleine die verschiedenen Möglichkeiten sind da erst mal zu prüfen um das richtige Verfahren zu finden:
    https://docs.microsoft.com/de-de/dotnet/standard/choosing-core-framework-server

    Und schlussendlich lohnt sich auch die eine oder andere Investition in Bücher;-).

    Mittwoch, 28. August 2019 16:24
  • In WebForms hast du auch bei vielen Dingen leichter Möglichkeiten etwas zu integrieren, die im Browser, egal welche Technologien zu verwendest, schwer oder gar nicht realisierbar sind. Dies sind aber häufig Themen die z.B. mit Dateien zu tun haben (Überwachung, Verarbeitung), dem Drucken (das ist in Web sogar einfacher :) ), oder gar Einbindungen von DLLs kann teils sehr schwer sein, mal aber auch total easy. Also alles was irgendwie "raus aus deinen Programmcode" arbeitet. 

    Leider wirst du nicht drum rum kommen, dich in die Oberflächensprachen Css und HTML einzulesen. Erleichtern kann dir Blazor als Technik das ganze. Da Blazor C# basiert ist (und kurz vor dem Release steht), wirst du viele Funktionalitäten übernehmen kommen und nicht ganz bei 0 anfangen müssen. Zusammen mit Bootstrap hast du bei der Oberfläche auch nicht so viel zu tun, wenn du erste Prototypen der GUI entwirfst. 

    An deiner Stelle, sollte deine Anwendung dann nur noch im Browser, intern wie extern laufen.

    Da ich vor etwa 2 Jahren vor den selben Problem stand, kann ich dir sagen, das das einarbeiten in das Thema schneller geht, als erwartet, zumindest wenn du schon mal mit WPF zu tun hattest, sind viele Konzepte sehr ähnlich. Ich habe nach etwa 6 Monaten mein Programm komplett umstellen können. (ca. 15 navigierbare Hauptbereiche). Die meiste Zeit floss am Schluss in das Design rein um es hübsch zu bekommen. 

    Freitag, 20. September 2019 09:09
  • Da kann man mal sehen, wie sich die Erfahrungen so unterscheiden.

    Web-Anwendungen sind in meinen Augen um ein vielfaches komplexer als einfache Web-Seiten.
    Hinzu kommt, dass der Serverteil der Anwendung sich mit vielen Dingen wie Multithreading, Shared Ressourcen und Lock's herumschlagen muss, da alle Clients mit demselben Prozess in unterschiedlichen Threads verarbeitet werden.

    WPF ist zwar ganz nett, erfordert aber nicht unerhebliche Grafikleistungen, die in Terminserver-Umgebungen aber häufig nicht zur Verfügung stehen.
    Nichts ist wirklich so schnell, wie Windows-Forms, das funktionioniert auch via RDP.

    Wir entwickeln daher nun unsere Web-Anwendung nun zusätzlich auf Forms, da die Web-Anwendung in vielen Dingen einfach überfordert ist (Performance!).

    Freitag, 20. September 2019 13:33
  • Hallo Manfred,
    ich kann nichts anderes schreiben: Windows Forms und Webanwendungen sind 2 paar Schuhe.
    Es beginnt mit dem MVC, den Du in MS Webanwendungen findest, der aber so in Windows Forms nicht verbreitet ist.

    Wenn Du aber schon dabei bist aktuelle Technologien anzuschauen, und um Zukunftsfähig zu sein, solltest Du Überlegen  auf .NET Core.3.0 zu wechseln. 
    Windows Forms ist zunächst einmal (im Normalfalll ) nicht komplett testbar, die aktuellen Technologien helfen hier und sollen allesamt komplett Testbar sein.

    Auf Browser(Client) Seite hast Du von MS sehr wohl ASP.NET und Blazor zur Auswahl, doch aus meiner Sicht ist hier Angular der vernünftigste Kandidat. 
    Aber das wären dann halt gleich 2 Schritte. 

    Die Kombination .NET Core + Angular  sind aus meiner Sicht ein mächtiges Gespann. Du kannst dann Webanwendungen erhalten die sich im Verhalten und vor allem in der Reaktionszeit nicht vor reinen Windows-Anwendungen verstecken müssen. 

    in Angular programmierst Du mit Typescript und das ist doch näher an C# als an javascript und lässt javascript fast vergessen. Du kannst hier, wie in C# Objectorientiert programmieren.Dein Typescript Code wird nach Javascript Transpiliert und aus Sicht des Entwicklers weggkapselt. Javascript siehst Du quasi nur auf der Webseite im HTML und dort gehört es auch hin.


    Ich schätze dieser Artikel kann ein guter Einstieg sein um zu schauen ob es passen kann:
    https://entwickler.de/online/windowsdeveloper/asp-net-core-angular-579873849.html

    Und ja: Es ist schon viel. 

    Grüße Alexander 




    Samstag, 21. September 2019 08:35
  • Wir haben eine Web-BI-Anwendung und die scheitert halt schon mal an den zu übertragenden Datenmengen zwischen Client und Server. Bis dann mal so ein Chart oder Grid gerendert ist, dass mehrere 1000 Werte verarbeiten soll, dann muss der User halt Geduld aufbringen.

    Und ein ganz großes Manko bei Web-Clients:
    Multithreading wird von JavaScript nur eingeschränkt unterstützt und bei Web-Assemblies komplett verboten.
    D.h., man kann die Ressourcen eines Clients nicht ausnutzen.

    In Forms, meinetwegen auch in WPF kann ich die volle Bandbreite eines Servers (den ich immer noch verwenden kann) als auch den Client ausnutzen und bin in vielen Dingen einfach blitzschnell.
    Und was das Testen angeht: Auch mit Forms kann ich Einzelkomponenten entwickeln und für jede Komponente Test-Abläufe erstellen.

    Bei einer klassischen ERP-Anwendung spielen solche Überlegungen halt keine Rolle, da größere Datenmengen im Client meist nichts zu suchen haben.

    Ich kenne halt im Laufe meiner Dienstjahre genug Anwender, die darüber klagen, dass die sog. "Transaktionsrate" (und damit ist nicht die DB gemeint, sondern ein Bearbeitungsvorgang) bei Web-Anwendungen häufig drastisch sinkt.
    Man muss sich also bei Web-Anwendungen genau überlegen, welche Anwendungsteile man darüber anbietet.

    Für die Technologie gibt es mittlerweile jede Menge verschiedene Lösungsansätze.
    Leider besteht dabei immer die Möglichket, dass man wie bei Silverlight oder Flash aufs falsche Pferd setzen kann:
    Silverlight => eingestellt
    Flash => von MAC/iOS nicht unterstützt

    Ich hoffe nicht, dass dies mit Blazor/Razor/Core nicht auch passiert. Aber da sei die Community vor;-).

    Samstag, 21. September 2019 08:53
  • Hallo,
    um große Datenmengen zu übertragen sollte, wenn möglich, etwas wie SignalR genutzt werden.
    Die binäre Übertragung zum Client soll schon helfen damit es schneller geht. 
    Grüße Alexander

    Samstag, 21. September 2019 10:02
  • Die verwendeten Tools (DevExpress) unterstützen bereits Datenkomprimierung.
    Das Problem ist ja, dass das Rendern eines Grids in HTML auf dem Server passiert.
    Außerdem werden Daten eher häufig in JSON übertragen was zusätzliche Rechenkapazität zum deserialisieren in Zahlen und Strings benötigt. Und dies kann dann schon mal ein paar MB mehr sein.
    Deshalb beschränkt man sich beim Web-BI auf hohe Aggregatstufen, so dass nur geringe Datenmengen anfallen.
    In einer Windows-App hat man diese Probleme erst gar nicht.
    SignalR wird bereits eingesetzt, was allerdings die Anzahl möglicher gleichzeitiger Verbindungen zum Server doch nicht unerheblich einschränkt da die SignalR-Verbindung i.d.R. permanent offen bleibt, allein schon um bei Trennung den Server frühzeitiger zu bereinigen.
    • Bearbeitet bfuerchau Samstag, 21. September 2019 13:15
    Samstag, 21. September 2019 13:14