patrick - Do 04.03.10 21:54
Titel: [Grundsätzlich] Aufbau von grafischen Programmen in C#
Hallo zusammen,
ich schreibe jetzt schon eine ganze Weile C#-Programme. Dies sind bisher immer Bibliotheken, Dienste etc.. gewesen und große GUI-Kenntnisse sind nie benötigt gewesen.
Nun bin ich über eine ziemlich banale Frage gestolpert:
Wie strukturiert man am besten ein Programm mit grafischer Oberfläche
Bei Delphi und anderen Programmiersprachen habe ich es eigentlich immer so gehandhabt:
Ein Beispiel:
Die in dem GUI wird die Aktion Click ausgelöst. Nun werden die passenden Funktionen im GUIBackend aufgerufen.
Das GUIBackend schaut z.B. welches Element in einem listview selektiert wurde, ordnet dies einem bestimmten Element in einem Array zu, welcher alle zusätzlichen Informationen enthält, dass das Programm benötigt (Dateiname, Größe etc.)
und Ruft tiefere Funktionen im Backend auf.
Die Funktionen für das GUIBackend habe ich immer in eine eigene Klasse gepackt.
Bei C# kann man jedoch ohne Invoke nicht auf die Elemente eines Forms zugreifen.
Ich suche nun nach einer Möglichkeit möglichst ohne Invoke (wegen mono) eine saubere Schnittstelle zwischen GUI und Backend zu erstellen.
Oder ist es in C# gar so gedacht dass man alle GUI-Relevanten Funktionen direkt in die Ereignisse setzt?
Mir kommt das immer irgendwie unsauber vor...
Wie baut ihr eure Programme auf?
Ralf Jansen - Do 04.03.10 22:11
| Zitat: |
| Bei C# kann man jedoch ohne Invoke nicht auf die Elemente eines Forms zugreifen. |
Das wäre nur nötig wenn du einen Crossthread Zugriff machst. Und unsynchronisierter Crossthread Zugriff sollte auch in Delphi ganz schlechter Stil sein auch wenn es Delphi nicht explizit unterbindet(oder doch?).
Aus Neugier wo ist das Problem mit Mono? Dort werden die Winforms Controls doch wohl auch ISynchronizeInvoke implementieren?
Moderiert von 
Christian S.: C#- durch Quote-Tags ersetzt
Christian S. - Do 04.03.10 22:43
patrick hat folgendes geschrieben  : |
| ich habe irgendwo gelesen das mono-programme kein invoke enthalten dürfen. |
Ich bin mir sicher, Du meinst
PInvoke, also das einbinden von Betriebssystem-Funktionen wie der Windows-API. Das hat mit der normalen Invoke-Methode nichts zu tun.
Ralf Jansen - Do 04.03.10 23:16
| Zitat: |
| fremde klassen haben auf controls innerhalb des forms ja keinen zugriff (private). |
Das kommt drauf an wie man die definiert(Stichwort Modifiers Property an der Form). Aber Standard ist private und das ist auch gut so. Direkt soll man da wirklich nicht dran aber mann kann der Form ja wiederum eine saubere Schnittstelle gegeben mit Methoden/Properties/Events von dennen aus man auf die eigenen Controls zugreift. Das Problem sollte sich aber eher seltener Stellen klassischerweise Sitz der Auslöser einer Aktion in der Form (oder noch genauer vor der Form z.b du). Man wird also wenn man richtigherum gedacht hat von der Form aus auf Schichten dahinter zugreifen um sich etwas zu holen (Funktionen/Daten us.w.). Der Fall das man etwas aus einer anderen Klasse in eine Form hineinschiebt sollte der seltenere Fall sein(jaja ich weiß es gibt auch andere Anwendungen).
| Zitat: |
wie baust du solche programme auf?
alle gui relevaten aktionen direkt in ereignis implementieren oder erstellst du zusätzliche funktionen innerhalb der form-klasse ( was mir momentan als der "richtigste" weg vorkommt). |
Üblicherweise bediene ich mich eines Patterns aus der MV... Umgebung (MVC, MVP, MVVM) oder benutze zumindest etwas das dem nahe kommt. Die ~zusätzlichen Funktionen~ würden also hauptsächlich in einer weiteren Klasse(n) stecken und nicht direkt auf der Form.