Hallo,

heute möchte ich eine Idee diskutieren, bei der ich gar nicht sicher bin, ob sie sich so realisieren lässt.

Bei der Frage WinForms oder WPF stellte sich mir die Frage, ob nicht beides geht. Ich stelle es mir so vor, dass eine Anwendung, in der die Funktion strikt von der Oberfläche getrennt ist, z.B. durch einen Kommandozeilenparameter, dazu veranlasst werden kann, einmal mit einer WinForms Oberfläche zu starten und ein anderes Mal mit einer WPF variante.

Es geht mir hierbei erst einmal gar nicht darum, wie nachher die Kommunikation zwischen den "Funktions-Klassen" und den "GUI-Klassen" aussehen muss sondern schlicht um die Frage wie muss das Hauptprogramm aussehen?

Immer vorausgesetzt, dass sich die beiden GUIs überhaupt in nur einer Anwendung vereinen lassen.

Gruß
Klabautermann

Hallo!

Ich würde schlicht die Programmlogik in eine Bibliothek packen und dann jeweils eine WinForms-Anwendung und eine WPF-Anwendung schreiben, die beide auf diese Bibliothek zurückgreifen. Dann kann jeder die Anwendung starten, die er haben will

Tatsächlich mache ich das bei meinem Programmen so (also Abtrennen in eine Bib), war bisher aber immer zu faul, wirklich zwei GUI-Versionen zu schreiben.

Grüße
Christian

Hallo,

was Christian schreibt sollte ja eh "Standard" sein. Ich denke er will insbesondere auf die Technologien WinForms u. Wpf eingehen. Also du kannst auch WPF-UC in WinForms hosten.

Du kannst dir also ein Programm schreiben welches die Konsolenparameter auswertet und dementsprechnd ein MainForm startet. Einmal ist es halt WinForms und das andere mal WPF. Allerdings bin ich mir nicht sicher ob du nicht in beiden Fälle das 3.5 Framework benötigst - ich vermute ja.

Gruß

danielf hat folgendes geschrieben :

Ich denke er will insbesondere auf die Technologien WinForms u. Wpf eingehen.

Ja, kann er bei meinem Vorschlag ja auch

danielf hat folgendes geschrieben :

Also du kannst auch WPF-UC in WinForms hosten.

Er will ja aber einmal eine WinForms- und einmal eine WPF-GUI. Und nicht eine WinForms-GUI in einer WPF-GUI hosten (oder andersrum). So habe ich es zumindest verstanden.

danielf hat folgendes geschrieben :

Du kannst dir also ein Programm schreiben welches die Konsolenparameter auswertet und dementsprechnd ein MainForm startet. Einmal ist es halt WinForms und das andere mal WPF. Allerdings bin ich mir nicht sicher ob du nicht in beiden Fälle das 3.5 Framework benötigst - ich vermute ja.

Womit es sinnlos wäre, noch WinForms zu benutzen, wenn das System eh schon die Anforderungen für WPF unterstützt.

Christian S. hat folgendes geschrieben :

danielf hat folgendes geschrieben : Du kannst dir also ein Programm schreiben welches die Konsolenparameter auswertet und dementsprechnd ein MainForm startet. Einmal ist es halt WinForms und das andere mal WPF. Allerdings bin ich mir nicht sicher ob du nicht in beiden Fälle das 3.5 Framework benötigst - ich vermute ja. Womit es sinnlos wäre, noch WinForms zu benutzen, wenn das System eh schon die Anforderungen für WPF unterstützt.

Genau und deshalb denke ich, dass er dies zuerst überprüfen muss -sonst macht es wenig Sinn.

Christian S. hat folgendes geschrieben :

danielf hat folgendes geschrieben : Ich denke er will insbesondere auf die Technologien WinForms u. Wpf eingehen. Ja, kann er bei meinem Vorschlag ja auch

Dachte dein Vorschlag geht mehr auf MVC ein und habe deshalb habe ich speziell nochmal WinForms/WPF hervorgehoben.

Gruß

Hallo,

und danke für eure Antworten Jungs. Das Ganze sind für mich erst einmal nur theoretische Überlegungen. Nichtsdestotrotz könnte sich daraus ein Standardvorgehen beim Entwickeln von .NET Anwendungen entwickeln. Im Hintergrund schwingen dabei ein wenig die Themen Kompatibilität und Zukunftssicherheit von Anwendungen mit. Insbesondere auch wie Passen ich meine Anwendungen am besten an, wenn MS noch ein weiteres tolles GUI-System entwickelt oder ich meine Anwendung z.B. zu einer Kompletten Netzwerk Anwendung ummodeln will. WPF unt WinForms stehen hier also auch als Beispiel für eventuell noch kommende Technologien.

Von daher ist Christians vorschlagt mit der Bibliothek gar nicht schlecht, denn er wird sicher immer gangbar sein.
Was mir an der Idee hingegen nicht gefällt ist, dass der Anwender selbstständig wählen muss, was er startet. Gut es passt zu meinem Beispiel mit dem Kommandozeilenparameter (da muss auch bewusst unterschieden werden) aber eine Anwendung, die abhängig vom Wochentag mal das eine oder mal das andere startet, ist auch nicht plausibel .

Dennoch würde mich interessieren, ob das auch in einer Anwendung geht. Lässt sich z.B. die ganze GUI in eine Bibliothek verlagern und dann entweder BibWPF oder BibWinForm laden?

Gruß
Klabautermann

Ja, generell lassen sich Libraries (Assemblies) auch mithilfe von Assembly.Load, Assembly.LoadFile bzw. Assembly.LoadFrom dynamisch laden.

Wenn du auch noch unterschiedliche .NET Versionen unterstützen willst (also z.B. .NET 2.0 für WinForms und sonst WPF), dann muß dein Startprogramm natürlich auf jeden Fall mit der kleinsten .NET-Version (hier also 2.0) erzeugt werden.

Ich selber würde dir jedoch auch den selben Vorschlag wie Christian S. machen, also einfach verschiedene Libs erzeugen und darauf aufbauend dann eigenständige Programme (je eines für WinForms und WPF) entwickeln. Die Logik-Lib kannst du ja dann mit Target ".NET 2.0" erzeugen (sofern du dann auf .NET 3.0 und höher Features verzichten kannst).

Th69 hat folgendes geschrieben :

[...] dann muß dein Startprogramm natürlich auf jeden Fall mit der kleinsten .NET-Version (hier also 2.0) erzeugt werden.

Da hinein dann aber z.B. eine 4.0-Assembly zu laden dürfte etwas schwierig werden, oder? Wenn wirklich anhand der .NET-Version entschieden werden soll, ist wahrscheinlich ein Bootstrapper in einer unmanaged Sprache nötig.