Hallo,

Ich habe eine grundsätzliche Architektur/Design Frage:

Ausgangslage:
Bestehende CRM/ERP Lösung in Access 2000/ SQL Server 2003 / VB6 dlls, über Citrix auf Terminalserver

Ziel:
Schrittweise Migration auf .NET

Nun, die bestehende Applikation ist sehr Umfangreich, und die einzige Möglichkeit ist eine Schrittweise Migration. So erstelle ich nach und nach in C# äquivalente Klassen und lagere so immer mehr nach .NET aus.
Diese werden dann von der alten Applikation eingebunden, bis dann einaml auch das Hauptgerüst auf .NET Migriert werden kann. Bis jetzt waren das alles Klassen ohne WinForms.

Es sollen in Zukunft auch teilweise GUIs im Internet zur Verfügung gestellt werden, wenn dies dann realisierbar ist, möglichst mit ähnlichem Komfort wie die aktuellen Winforms. (also keine php/html/javascript Geschichte) Auf was muss ich besonders achten, wenn ich später teile der .NET Klassen, vielleicht sogar WinForms übers Netz zugänglich machen will?

Das fängt bei den WinForms an (sollte man besser mit WPF Controls arbeiten?) Ich habe mich mit WPF noch nicht beschäftigt, aber nach dem überfliegen einiger Artikel könnte das eine perfekte Lösung sein, um die Applikation (bez. Teile davon) ohne Terminalserver zur Verfügung zu stellen?

Hat jemand grundlegende Tipps in die Richtung, Lektüre usw?

Hallo,

ich denke, dass WPF den Rahmen sprengt. Das Migrationsprojekt scheint eh schon groß genug zu sein. Zusätzlich gleich auf WPF zu gehen würde "unnötig" viel Mehraufwand generieren.

Wenn du es im Internet zur Verfügung stellen willst kannst du auch ASP.NET nehmen - anstelle von php/html/javascript. Soll es aber einfach eine verteilte Anwendung sein, kannst du auch WinForms verwenden. Für die Kommunikation mit dem Server rate ich dir zu WCF. Damit hast du große Vorteile wenn du innerhalb von .NET entwickelst und kannst dennoch durch Verwendung von WebSerivces jederzeit andere Technologien anbinden (warum auch immer ).

Die Ausgaben von Microsft Presse sind immer recht interessant und gut strukturiert:

Microsoft Windows Communication Foundation Step by Step

Gruß

Erstmal Danke für deine Ausführungen

danielf hat folgendes geschrieben :

Hallo, ich denke, dass WPF den Rahmen sprengt. Das Migrationsprojekt scheint eh schon groß genug zu sein. Zusätzlich gleich auf WPF zu gehen würde "unnötig" viel Mehraufwand generieren.

Das wäre natürlich das Gegenteil des gewünschten Ergebnisses. Da ich sowieso die GUIs neu machen muss, dachte ich, es gäbe evtl eine Lösung, dass ich nicht alle diejenigen die ich übers Netz benötige nochmals neu schreiben muss.

Was aber sicher problemlos geht, ist die eigentliche Logik vom View zu trennen - und diese dann entweder mit ASP.NET/Silverlight was auch immer zu visualisieren.

Zitat:

Wenn du es im Internet zur Verfügung stellen willst kannst du auch ASP.NET nehmen - anstelle von php/html/javascript. Soll es aber einfach eine verteilte Anwendung sein, kannst du auch WinForms verwenden. Für die Kommunikation mit dem Server rate ich dir zu WCF. Damit hast du große Vorteile wenn du innerhalb von .NET entwickelst und kannst dennoch durch Verwendung von WebSerivces jederzeit andere Technologien anbinden (warum auch immer ).

Innerhalb der Firma ist das TerminalServer Umfeld ganz ok, ein paar Aussendienstmitarbeiter kommen ebenfalls über VPN auf den Terminal Server. Das ist ganz ok so (obowhl es anscheinend heutzutage eher der Trend in Rrichtung Web2.0 und weg vom Terminalserver Umfeld ist!?)

Aber die Kunden sollen sich über ihre Aufträge selber ein Bild machen können, und da sind komplexe Winforms mit viel Geschäftslogik gewünscht. (Welche alle schon intern für die Mitarbeiter existieren)

Wenn ich nun diese Winforms über Web2.0 zur Verfügung stellen könnte, würde das einiges vereinfachen.

Zitat:

Das wäre natürlich das Gegenteil des gewünschten Ergebnisses. Da ich sowieso die GUIs neu machen muss, dachte ich, es gäbe evtl eine Lösung, dass ich nicht alle diejenigen die ich übers Netz benötige nochmals neu schreiben muss. Was aber sicher problemlos geht, ist die eigentliche Logik vom View zu trennen - und diese dann entweder mit ASP.NET/Silverlight was auch immer zu visualisieren.

Wie du im zweiten Satz selber nochmal verdeutlichst 'muss' die Logik von der Präsentation getrennt sein. Die Logik muss einfach als verteilte Anwendung realisiert werden. Für die Anzeige gibt es dann WinForms oder WPF im .NET-Umfeld. WPF ist sehr Aufwendung und eher für Anwendungen mit hohen grafischen Anforderungen (Animationen, Styles, ...) gedacht.

TerminalServer zu verwenden ist ein komplett anderer Ansatz. Dieser hat nichts mit der Applikation an sich zu tun (auch nicht VPN), sondern bietet nur die Möglichkeiten Anwendungen die auf anderen Servern laufen lokal anzuzeigen.

Mit Web 2.0 meinst du glaub ich SOA??? Dabei geht es nur darum, dass die Anwendung dienstorientiert aufgebaut ist und eben das MVC-Konzept noch erweitert. Für diese Umsetzung ich dir zu WCF raten.

Nochmal zusammenfassend:
Du migrierst sämtliche Klasse auf .NET und implementierst zusätzlich WCF Schnittstellen. Will der Kunde ein "gewöhnliche" Windows-Anwendung haben implementierst du WinForms zur Darstellung. Soll die Anwendung per WebBrowser bedienbar sein ASP.NET und für eine grafisch aufwendigere Lösung nimmt man WPF.

Zitat:

Wenn ich nun diese Winforms über Web2.0 zur Verfügung stellen könnte, würde das einiges vereinfachen.

Du kannst eine WinForms-Anwendung zur Darstellung programmiere und die Kommunikation mit dem Server über Web 2.0 Standards (á la WebServices) machen.

Ich hoffe du kannst es dir vorstellen.

Ich werde mich jetzt mal ausgiebig mit WCF beschäftigen, um dann evtl. nochmals konkretere Fragen stellen zu können.

danielf hat folgendes geschrieben :

WPF ist sehr Aufwendung und eher für Anwendungen mit hohen grafischen Anforderungen (Animationen, Styles, ...) gedacht.

Manche würden wahrscheinlich eher behaupten, dass Data Binding + MVVM ein unschlagbares Team für Line-of-Business-Anwendungen darstellt und WPF sicherlich eine äußerst steile Einstiegskurve besitzt, was sich aber danach bei jedem Unit-Test eines View-Models auszahlt. Oder so ähnlich .

In puncto WCF wären vielleicht noch die WCF RIA Services interessant, die quasi den O/RM auf dem Server über das Netzwerk erweitern und so auf dem Client LINQ, Change Tracking und den ganzen restlichen Spaß bereitstellen - allerdings nur für Silverlight, was wohl sowieso der "GUI im Internet" am nächsten kommt. ASP.NET ohne ".../html/javascript" stell ich mir jedenfalls schwierig vor .

WPF scheint nicht ganz das richtige zu sein, macht zwar nette GUIs, aber hier stehen andere Dinge im Vordergrund.

Kha hat folgendes geschrieben :

[...]allerdings nur für Silverlight, was wohl sowieso der "GUI im Internet" am nächsten kommt.[..]

Silverlight hatte ich eigentlich auch eher im Auge als ASP.NET. Evtl ist Silverlight sogar für lokale GUIs brauchbar, das muss ich noch testen. - Denn Performance geht vor. WCF wird später ein Thema sein, aber aktuell kann ich das Kernstück der Applikation noch nicht migrieren - und WCF stellt ja so ziemlich das Kernstück der Applikation dar.

Danke für eure bisherigen Erklärungen - bin halt doch noch sehr neu mit den neuen Techniken