Nehmen wir an du hast in WPF zwei getrennte Projekte. Views und ViewModels. Das ViewModel kennt keine Views also musst du mit Service/Interface arbeite. In deiner Views legst du am einfachsten einen Service an der das für dich übernimmt.
Jetzt stehst du vor dem Problem, du musst diese ViewModel(wpf) in Windows Forms übernehmen. Aber das ViewModel aus der WPF kennt kein DialogResult oder sonst was aus WindowsForms.
Soll es auch gar nicht kennen,das soll sich ja nur um Daten kümmer und nicht um die UI oder Views.
Dafür kennt es vielleicht ein IDialogService der sich in einem Core Projekt befindet oder so. Dem Viewmodel ist das Egal Wo das IDialogService herkommt, ob aus WPF oder WindowsForms oder sonst woher. Es kann diesen Ausführen und was der macht ist ihr auch egal.

Hab dein Projekt etwas überarbeitet und hier mein Vorschlag, ganz einfach gehalten.
Ich bin auch nicht so gut in der Programmierung da ich alles nur Hobbymässig betreibe.
Aber so würde ich es machen.
Man müsste es genau testen in verschiedenen Projekten um zu sehen ob es funktioniert.
Ist nur für das Verständnis. Man kann darauf Aufbauen glaub ich.
Es geht noch besser wenn man sich da die zeit nimmt und es besser durchdenkt mit den Service.

VaporiZed schrieb:

Ich fasse zusammen: DialogService ans View anpassen und abstrakt dem VM bekannt geben. Der DialogService kümmert sich ums Form oder das WPF-Window.

Genau so hab ich es mir gedacht. Wenn du das Muster beibehälst wird es nachher für den DI-Container sehr Hilfreich sein.
Alles was von aussen kommt sollte über ein Service kommen. Überleg mal, Net Maui kennt keine Usercontrols und WPF kennt keine Forms und Blazor und WInUi und was es da noch so gibt. Also alles was die UI angeht über Interfaces und Services. Den Service kannst du ja jedezeit austauschen solang er das Interface implementiert .Du willst ja deine ViewModels nur einmal schreiben und nachher in verschiedenen Projekten benutzen. Also vielleicht eine APP oder in Wpf oder in WindowsForms wie gerade eben. Da kann das ViewModel nicht Dinge mitbringen die aus eine anderen UI-Technologie stammen.

Und wenn es sein muss machst du es halt in der View im Code Behind , ist ok wenn es nur der grafischen Darstellung dient.Das verwirrt die Leute immer.
Ist Geschmacksache aber sollte keine feste Regel sein.
Gerade am Anfang , wenn man es nicht übertreibt

Aber ist es nicht bei jedem VB6/VB.NET Anfänger so, dass man mit Winforms beginnt und dann den kompletten Code (meist aus Unwissenheit) direkt in der Form verwaltet?

Ich habe nie programmieren gelernt. Ich habe ca. 2002 mit VB6 meine ersten Versuche gewagt.

2005 habe ich meine erste Kassensoftware mit VB6 geschrieben und diese Software hat sich 13 Jahre lang am Markt etabliert - obwohl in VB6 und der meiste Code in den Forms.

2020 habe ich bereits die dritte Version mit VB.NET 4.5 ebenfalls in Winforms herausgebracht. Hier ist nur noch ganz wenig Code in der Form selbst. Das meiste wurde bereits in Modulen (Klassen sind "noch" nicht so meins") untergebracht.

2023 habe ich es dann aber von Grund auf richtig gemacht und Code und GUI getrennt. Aber auch hier wieder nur mit Winforms. Obwohl man der Anwendung das Winforms gar nicht mehr ansieht.
Die runden Buttons in der BOPV.uno Anwendung sind tatsächlich echte Button-Controls mit dem Verhalten von Buttons. Zeichnen mit e.graphics ist jetzt auch kein Schreckgespenst mehr und in dieser Anwendung werkeln sogar über 10 Background-Worker.

WPF habe ich mir kurz mal angesehen - ist aber für mich zu abstrakt und ich kann mich da nicht wirklich umgewöhnen. Aber solange ich alles auch mit Winforms hinbekomme, ist es für mich ok.

Auf diesem Wege möchte ich mich auch herzlich bei allen hier im Forum bedanken. Durch Euch habe ich sehr viel gelernt. Hoffentlich konnte ich auch hie und da etwas mit kleinen Tipps zurückgeben.

Nicht dass wir uns falsch verstehen. Das ist eine Quick and Dirty Lösung, die nur den Weg aufzeigen soll und nur für WinForms und Momentan gedacht ist.
Normalerweise sollte man sowas vermeiden und stattdessen Techniken wie CommandParameter oder andere Methoden verwenden.
Bei mir hat das mit CommandParameter in WindowsForms nicht funktioniert.
Es ist gut möglich das Binding in WindowsForms noch nicht ausgereift ist.
Vielleicht kommt das noch mit den CommandParameter.
Wenn jemand weiß wie man CommandParameter angibt kann man den Service so umbauen das
die Form über CommandParameter eingereicht wird. Das wäre dann evt. ein bessere Lösung.
Man kann auch evt. das DialogResult der Form direkt an die Property des DialogService binden und Manipulieren...

Amro schrieb:

kann man den Service so umbauen das...

mal dumm dazwischengefragt: Was versteht ihr unter "Service"?
Bei mir gibts Services als Bestandteil einer Server-Client-Netz-Architektur, da kann sein, dass ein Service mw. bestimmte Anfragen beantwortet, indem er Daten zurückschickz.
Also Service hat bei mir was mit Netzwerken zu tun, mehrere Anwendungen, und Daten herumschicken.

Einen Dielog von einem Service abrufen - das geht über meinen Horizont. Bei mir sind Dialoge Bestandteil der Client-Anwendung, und kann man keinesfalls iwo anders hin verfrachten, und dann abrufen.
ein Dialog ist ja kein Datenpaket.

Durch das Tutorial von Nofear23m habe ich auch eine Weile "Service" im namen verwendet, scheint sich durch das Tutorial hier so eingebürgert zu haben. Aktuell verwende ich Benamungen mit Dependency und Contract. Denn das was Nofear23m in dem Tutorial zeigt, ist eine minimale Variante von Dependency-Injection. Daher sind Namen wie IDependencyContract, TDependencyContract oder IWindowDependencyContract IMO passender als wie was mit Service. Wenn ich an einen Service denke, denke ich eher an Windows-Services, also diese, die man im services.msc controlpanel starten und stoppen kann.

VaporiZed schrieb:

Contract - Vertrag?

Ja genau! Das Basis-Interface heist bei mir IDependencyContract(siehe den ServiceContainer im Tutorial, im kapitel mit den services, daher erwähnte ich auch den namen mit beginnendem T). Dazu hab ich dann weitere Interfaces die dieses inne haben. Z.B. IMainWindowDependencyContract Dependency halt weil das eine kleine DI-Variante ist. Wobei vertragsbedingung noch passender wäre, man muss ja diese Interfaces implementieren, welche halt vorschreiben welche Funktionen/Methoden dann in der Klasse zu sein haben. So hat man Abhängigkeiten die Klasseninstanzen die das interface inne haben, und wie du auch schon sagtest Contract ist fast schon ein Interface.

Ja, ich könnte einfach das Interface IMainWindowDependencyContract nennen was ich ja tu, die klasse die das dann implementiert einfach MainWindowDependency, aber ich hab das syncron, ich lasse dann nur das I weg.

ErfinderDesRades schrieb:

Server-Client-Netz-Architektur,

Ich glaub das Trifft es schon gut. In MVVM bietet ein Service Dienste an, die von ViewModels angefordert werden können.
Services in MVVM Entkopplt ViewModels und Views.
ViewModel ist es egal wie der Service das macht,Will nur die View oder Window.
Server entkoppelt Serverkomponete von Client.
Client ist das auch egal

Das hat bestimmt auch was mit der Projektmappe Struktur zu tun.
In grösseren ProjektenMappen findet man oft eine [App].Services Projekt die Klassen beinhalten, die mit Service enden.


Ein Manager kontrolliert und koordiniert mehr Daten und Ressourcen, während ein Service eher Funktionalität bietet,
wie beenden des Dialogs in dem fall,den das ViewModel nicht kennt, aber von der View angefordert wird.
Also meistens redet man von Service aber Manager sehe ich bei meinen recherchen auch hin und wieder.

ErfinderDesRades schrieb:

Einen Dielog von einem Service abrufen - das geht über meinen Horizont. Bei mir sind Dialoge Bestandteil der Client-Anwendung, und kann man keinesfalls iwo anders hin verfrachten, und dann abrufen.
ein Dialog ist ja kein Datenpaket.

Es wird kein Dialog aufgerufen nur die Eigenschaften des Dialogs die gebunden sind werden geändert.

Ja Manager passt sehr gut die Klasse welche ich nutze für die "Services", nenne ich DependencyManager. Ich hab "Service" bei mir ja nicht mehr in den namen drin.

Ich hab mich für Service entschieden weil ich in WPF ein NavigationService gebaut hab
was zwischen den Views(UserControls) die auf meine Window sind hin und her Navigiert.
In dem Projekt kommt warscheinlich auch der DialogService rein wenn ich den irgend wann mal brauche
Manager will ich aufheben für zum Beispiel FileManager oder ImageManger und so .
Dinge die Daten betreffen und irgendwie verarbeitet werden müssen.
Aber wichtig ist glaub ich das man da etwas trennt für sich selbst, weil mit der Zeit kommen immer mehr Projekte hinzu die irgenwelche Aufgaben erledigen. Und das man selber durchblickt