Stilfrage - trennen "verarbeitenden Code" und Grafik/Dialoge

[VizeTE]

Hallo Leute,

für die Wiederverwendbarkeit von Code ist es ja bekanntlich sehr förderlich wenn man die Benutzerschnittstelle (Formulare, Dialoge, ...) vom eingentlichen verarbeitenden Code trennt.
Da habe ich so kleine Stilprobleme und würde mich freuen wenn ihr mich an eurer Erfahrung teilhaben laßt. :wink:

Mal etwas konrekter:

Ich habe mein Hauptformular. Dies benutzt für die eigentlichen Arbeiten ein Objekt. Nun ist es aber hin und wieder erforderlich, daß der Benutzer für die Arbarbeitung Daten eingeben muß. Da das Benutzerinterface vom Code getrennt werden soll kommt es nicht in Frage, daß das Objekt für die Dialoge verantwortlich ist. Ich habe nun 3 Lösungsansätze wobei ich aber von keinen der Möglichkeiten vollends überzeugt bin.

1. Ich definiere ein Event (procedure of object), welches im Hauptformular bearbeitet wird. Dort wird der benötigte Dialog aufgerufen.
Vorteil:
- Das Objekt muß sich nicht im entferntesten um den Dialog kümmern
Nachteile:
- die Parameterlisten können recht lang werden
- die Events müssen im Hauptformular behandelt werden

2. Ich übergebe beim Aufruf einer Methode des Arbeitsobjektes die erforderliche Dialogklasse. In der Methode kann mit dem Dialog gearbeitet werden
Vorteile:
- ich habe nicht das Parameterproblem
- der Dialog kann ausgetauscht werden sofern die Schnittstelle kompatibel
Nachteile:
- die Trennung von Interface und Code wird aufgeweicht
- ich muß bei jedem Aufruf alle nötigen Dialoge übergeben, auch wenn diese nur manchmal tatsächlich benutzt werden

3. Ähnlich Ansatz 2 aber das Objekt bekommt eine Eigenschaft pro Dialog. Im Hauptformular wird der Dialog an das Objekt "angehangen".
Vorteile:
- ebenfalls wird das Parameterproblem umgangen
- Dialog kann ausgetauscht werden sofern die Schnittstelle kompatibel
Nachteile:
- der Dialog muß angehange sein damit der Ablauf funktionieren kann
- Trennung von Interface und Code wird auch hier aufgeweicht

So ich hoffe ihr versteht was ich meine. Für Anregungen, Meinungen usw. bin ich dankbar.

Ciao

[mschaefer]

Noch eine Variante:

Baue Dir ein Dialogobjekt, das Du mit Deinem Rechenobjekt verlinkst. Dann hast Du im Formular nur die beiden Objekte liegen. Du könntest eventuell die Texte auch frei definierbar machen. Letzlich hängt das aber alles daran, wie häufig Du diesen Code wiederverwendest.

Grüße // Martin

[VizeTE]

mmm...entspricht dieser Ansatz nicht meiner Lösung Nr 3, spricht das der Dialog per Property/Eigenschaft an das Objekt gehangen wird? (So hätte ich "linken" in diesen Zusammenhang umgesetzt)
Oder verstehe ich dich da falsch?

Ich weiß nicht ob das eindeutig rübergekommen ist...es soll nicht nur ein Ja/Nein-Dialog verwendet werden (Wobei dieser einfach Ansatz nicht auschgeschlossen werden muß). Aber auch komplexe Anwendungsfälle müssen abgedeckt werden.

[Grendel]

Du könntest deine Dialoge von einer gemeinsamen Basisklasse ableiten und diese als Typ des Propertys nutzen. Damit muss das Object nur die Basisklasse nicht aber die konkrete Implementierung kennen.
Über abstrakte Methoden oder Interfaces kannst Du dann die Kommunikation erschlagen.

Eine weitere Möglichkeit ist der Einsatz des MVC-Pattern (Model, View, Controller). Dabei ist der Controller die Schittstelle zwischen datenhaltendem Model und darstellenden View.

Bis neulich ...

[VizeTE]

Die Idee mit der Basisklasse wollte ich mit meinen Lösungsansätzen 2 & 3 ansprechen. Ich bin mir aber selbst noch nicht so recht klar ob das für mich eine gute Lösung ist. (nicht auf ein konkretes Problem bezogen sondern ob ich für mich sagen kann "das ist die Lösung")

Dieses MVC-Pattern klingt auch interessant. Ich habe schon mal versucht mir einen groben Überblick zu verschaffen. Das geht dann wohl mehr auf den Lösungsansatz 1 zurück.
Werde ich mir aber bei Gelegenheit nochmal genauer anschaun

Danke

[freak4fun]

Versuch doch einfach mal alle Lösungen. :drunken: Die erste ist meistens nicht die Beste, aber nach und nach wirst du dich der perfelten Lösung immer mehr nähern. :zwinker: Fang an! :angel:

MfG
freak

[Phoenix]

Zitat:

Zitat von Grendel

Eine weitere Möglichkeit ist der Einsatz des MVC-Pattern (Model, View, Controller). Dabei ist der Controller die Schittstelle zwischen datenhaltendem Model und darstellenden View.

Hätte ich jetzt auch vorgeschlagen.
Interessantes Beispiel:

Der Controller selber kennt das Business-Object (das 'Rechenobjekt') und die View (also alle Forms und Dialoge).

Je nach Anwendungsart kann der gleiche Controller daher z.B. einen Dialog aufpoppen lassen oder aber gar in einer Webanwendung eine neue html-Seite generieren. Sollte die Anwendung komplett ohne Interaktion laufen (Batch-Betrieb) könnte der Controller sogar dazu angewiesen werden, immer nur die gleichen Informationen zu liefern die ein einziges mal vorgegeben werden etc.

Ich denke, das ist der sauberste Ansatz.

[VizeTE]

Zitat:

Zitat von freak4fun

Versuch doch einfach mal alle Lösungen. Die erste ist meistens nicht die Beste, aber nach und nach wirst du dich der perfelten Lösung immer mehr nähern. Fang an!

Das habe ich natürlich schon gemacht aber das war nicht so richtig erfolgreich. Funktioniert hat es schon aber der Lösungsweg hat mich nicht so richtig überzeugt.

Zitat:

Zitat von Phoenix

Der Controller selber kennt das Business-Object (das 'Rechenobjekt') und die View (also alle Forms und Dialoge).

Je nach Anwendungsart kann der gleiche Controller daher z.B. einen Dialog aufpoppen lassen oder aber gar in einer Webanwendung eine neue html-Seite generieren. Sollte die Anwendung komplett ohne Interaktion laufen (Batch-Betrieb) könnte der Controller sogar dazu angewiesen werden, immer nur die gleichen Informationen zu liefern die ein einziges mal vorgegeben werden etc.

Wenn ich das MVC-Pattern richtig verstanden habe dann kenn aber das Buisnessobjekt nicht den konkreten Controller. Nur eine abstrakte Version, die über Veränderungen benachrichtigt werden kann.
Und da liegt, meiner Ansicht nach, das Problem. Ich möchte gern vom Businessobjekt einen Dialog/Formular aufpoppen lassen. Hier weiß ich keinen richtig guten Ansatz. Mir fallen nur die Lösungswege aus meinem ersten Posting ein.

(Wo liegt eigentlich der Unterschied zum Observer-Pattern? Das MVC scheint mir eher eine konkrete Anwendung des Oberservers)

[marabu]

Zitat:

Zitat von VizeTE

Ich möchte gern vom Businessobjekt einen Dialog/Formular aufpoppen lassen.

Dann hast du keine MVC-Architektur mehr.

Zitat:

Zitat von VizeTE

Wo liegt eigentlich der Unterschied zum Observer-Pattern? Das MVC scheint mir eher eine konkrete Anwendung des Oberservers

Der Observer dient der Koordinierung von aktiven Objekten. Der Controller der MVC-Architektur ist kein Observer, sondern die Befehlsschnittstelle deiner Anwendung.