.NET GUI

Hallo!

Beim Lesen von prog1's Threat Welche Technologie soll man denn überhaupt verwenden...  bin ich ins Grübeln gekommen, wie die GUI von dem Anwendungscode getrennt wird. Wie genau wird das am besten gemacht? Könnte mir vorstellen, den Anwendungscode in eine .dll zu stopfen und die GUI in eine weitere.

Und wie stellt ihr das im Visual Studio an? Alles in eine Arbeitsmappe?

Gibt es dafür Best Practices?

Grundsätzlich empfehlenswert zu diesem Thema: http://blogs.sqlxml.org/bryantlikes/archive/2006/09/27/WPF-Patterns.aspx

Dein Ansatz ist schon richtig. Sämtliche Logik, Datenklassen etc. alles in eine separate DLL (können auch mehrere sein, hängt davon ab, was du wie zusammenfassen möchtest). Diese wird nun in dein Oberflächen-Projekt (beispielsweise WPF-Anwendung) eingebunden.

Plakativ würdest du dann beispielsweise einen Controller haben, der bestimmte Aufgaben übernimmt (beispielsweise das befüllen eines Personen-Objektes). Der Controller liefert nach Aufruf der Methode FillPerson(Int64 id) ein Objekt vom Typ Person zurück, welches dann per DataBinding an die Oberfläche gebunden werden kann.

Das wäre es jetzt einfachst erklärt. Hilft dir das so weiter? Oder benötigst du ein Beispiel zum besseren Verständnis?

Ich denke das Grundprinzip ist klar. Im Prinzip liegt der Anwendungscode in der/den .dll und die GUI in der .exe.

Welche Aufgabe genau hat der Controler? Übernimmt der die Funktion des 'Bindegliedes' zwischen GUI und Code, und muss dann folglich für jede neue GUI ebenfalls angepasst werden?

Der Controller hat die Aufgabe, auf Benutzerinteraktionen zu reagieren, Daten zu laden bzw. zu aktualisieren etc. Normalerweise sollte er nicht geändert werden müssen, nur weil sich die GUI ändert.
Das kann man sich so vorstellen:

User klickt auf Button -> Event -> In diesem Event wird eine Methode des Controllers aufgerufen > Ergebnis wird zurückgegeben (Daten, oder was auch immer).

Dieser Vorgang sollte unabhängig davon ob es sich um eine Windows Forms Anwendung handelt oder eine ASP.NET Webanwendung gleich funktionieren.

Wie bereits erwähnt, guck dir einfach mal das verlinkte Pattern an, da sind Beispiele drinnen die das veranschauchlichen.

OK ich habs vorhin nur grob überflogen (offensichtlich zu grob^^) - ich les es mir durch

Vielen Dank soweit!

Ist etwas viel zu lesen, aber es wird ein Pattern gezeigt, mit dem es unter WPF recht einfach ist, GUI von der Logik zu trennen. Bezieht sich eben jetzt nur auf die WPF, für WinForms etc. gibt es andere Patterns (MVC), die da recht sinnvoll sind. Ist aber nicht so tragisch, denn das verlinkte Pattern ist nur eine Weiterentwicklung des MVCs bzw. eine passende Abänderung.

Ich hab auch das hier gefunden - das Zauberwort welches mir bis jetzt gefehlt hat war 'MVC' ;)

Bei WinForm kannst Du auch noch nach MVP-Pattern suchen.

Für WPF würde ich mir je nach Umfang der App auch noch Prism angucken.

Danke dir Norbert für den Link, kannte ich bis jetzt nicht. Das DM-V-VM war mir zwar ein Begriff aber durch die Serie, wird es sehr gut dargestellt, was das alles beinhaltet :-)

Auf Basis dieses Patterns fällt es dann auch nicht wirklich schwer, ein richtiges Softwaredesign für die eigenen WPF-Anwendung zu finden.

Dafür kann ich dir ein paar Best Practices aus der Praxis nennen, die teilweise produktiv sind oder kurz vor der Fertigstellung - mit andern Worten: sie funktionieren nicht nur als Pattern  ;-)

Die Frage, die du aber zuvor beantworten musst: Wie sehr willst du trennen?

a) Komplett:
- dynamisches Laden von Anwendungsmasken,
- lose Kopplung von Events über Namen
- XML Steuerdateien binden Logik und GUI zusammen

b) Klassisch
- dynamisches Laden von Modulen
- Module kommunizieren über Services mit Core und anderen Modulen
- lose Kopplung von GUI und Komponente durch Interfaces (sehr klassisch ;-) )

c) Design / Code
- XAML im Blend
- C# in VS
- Code Behind so dünn wie möglich
- zentrale Steuerung