AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Delphi Trennung von GUI und Logik, wie geht ihr vor?

Trennung von GUI und Logik, wie geht ihr vor?

Ein Thema von divBy0 · begonnen am 19. Aug 2011 · letzter Beitrag vom 8. Dez 2017
Antwort Antwort
Seite 4 von 18   « Erste     234 5614     Letzte » 
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
3.541 Beiträge
 
Delphi XE3 Ultimate
 
#31

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:24
Das stimmt, aber um so größer und komplexer ein Projekt werden wird, um so wichtiger wird eine Trennung.
Es ist eine Frage des Frameworks, wie komfortabel die Bindung der beiden Ebenen realisiert werden kann.
Die Erstellung der Datenebene und der GUI-Ebene für sich sollte jeweils einfacher und übersichtlicher werden.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
SebE

Registriert seit: 31. Jul 2004
Ort: Chemnitz
316 Beiträge
 
Delphi 7 Personal
 
#32

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:27
Aber genau darum geht das doch das entkoppeln. Das es eben genau nicht mehr im Code steht sondern lediglich noch Deklarativ geschieht.

Wenn Du das im Code machst, produzierst Du zum einen wieder viel mehr Code (der neue Fehler enthalten kann), zum anderen verlierst Du genau die Flexibilität, die solche Binding-Mechanismen gerade erlauben sollen.
(fett durch mich)
Punkt 1: stimmt absolut.
Punkt 2: Ich weiß gerade nicht, was ich von Hand nicht machen könnte, was mir Bindings erlauben.

Der Trick ist doch genau der, Elemente austauschen zu können, die nichts voneinander wissen. Code muss zwangsläufig auf beiden Seiten die Details kennen, um sie aneinander zu koppeln. Deklaratives binding hingegen erlaubt es Dir, sowohl die View als auch das Model auszutauschen, ohne dass es hier zu einer Code-Änderung an irgend einer anderen Stelle kommen muss.
Beim Verbinden muss immer Information offen gelegt werden.
Beim Binding muss man angeben, welche Property verwendet werden soll.
Ich mache das mit Abstraktionen, die das - und nur das - enthalten, was der Benutzer der konkreten Implementierung wissen darf.
Schnittstellen muss man immer angeben.

Klar ist es mehr Aufwand, aber so viel auch wieder nicht: nach dem Anpassen der Schnittstelle, die richtigen Objekte erzeugen.
Vorteil: der Compiler sagt mir, wenn ich falsche Informationen beziehen möchte.

Das ist ja auch genau das Problem an MVC: Der Controller muss View und Model kennen, um sie aneinander zu docken.
(fett durch mich)

Dass der Controller das Model kennen muss, ist eigentlich kein Problem (meine Controller rufen nur Model-Methoden auf).
Für den markierten Teil wird ein Presenter eingefügt, von dem der Controller auch nur die Abstraktion kennt.

Meine Architektur:
Model: klar!
Controller: wählt zu Beginn den Presenter/die View aus; bestimmt, was die Anwendung kann; leitet Anweisungen an Model
Presenter: UI-Logik (Weiterleiten von Eingaben); Formatierung der Ausgabe ;Erzeugen von UI-Objekten auf Anfrage des Controllers (auf Anfrage des Models)
View: Leitet Eingabe-Events an den Presenter weiter; sieht trollig aus
Sebastian
  Mit Zitat antworten Zitat
Benutzerbild von divBy0
divBy0

Registriert seit: 4. Mär 2007
Ort: Sponheim
1.016 Beiträge
 
Delphi XE2 Professional
 
#33

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:30
Nativ wie gesagt mit meiner Library ab Delphi 2010. Das Prinzip dahinter ist aber genauso mit Delphi 7 realisierbar (halt mit einigen Abstrichen bzgl der RTTI und Generics z.B.)

Eingangsbeispiel mal mit meinen DataBindings realisiert im Anhang
Das Beispiel funktioniert bei mir aber nicht. Der Button löst keine Addition aus.

Memory Leaks gibt's auch:

---------------------------
Unexpected Memory Leak
---------------------------
An unexpected memory leak has occurred. The unexpected small block leaks are:



1 - 12 bytes: Unknown x 1

21 - 28 bytes: TList<System.TMethod> x 1

29 - 36 bytes: TEventHandlerInstance x 1

45 - 52 bytes: TEventHandler<DSharp.Bindings.TPropertyChangedEven t> x 1

69 - 76 bytes: TNotificationHandler<TEventHandler<DSharp.Bindings .TPropertyChangedEvent>> x 1



The sizes of unexpected leaked medium and large blocks are: 52012


---------------------------
OK
---------------------------
Marc
9 von 10 Stimmen in meinem Kopf sagen ich bin nicht verrückt, die 10. summt die Melodie von Tetris... | Wenn das die Lösung ist, dann hätte ich gerne mein Problem zurück! | engbarth.es
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.324 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#34

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:31
OOP bis zum "Gehtnichtmehr"! Delphi ist für mich ein RAD-Tool und OOP ist kein Dogma. Es gibt nun einfach Dinge, die im praktischen Entwickleralltag sinnlos sind. Eine strikte Trennung von GUI und Anwendungslogik ist in Delphi nicht immer zwingend und verhindert manchmal sogar die Übersichtlichkeit und Lesbarkeit des Codes bei kleinen Projekten. Leider habe ich den Link nicht mehr gefunden, aber irgendwer hat mal ein Horrorbeispiel in OOP für ein Hello-Word Programm geschrieben (vielleicht kennt ja hier jemand das Beispiel). Also meine Ansatz: Auslagerung in externe Klassen nur dann wenn es Sinn macht und/oder die Lesbarkeit des Codes verbessert.
Wer schonmal an einem Projekt gearbeitet hat, wo trotz Mockups plötzlich die Entscheider der Meinung war, dass der Workflow für den Benutzer ja so mal garnicht geht und man das ganze doch ganz anders bedienen und darstellen muss, wird geflucht haben, wenn er dann überall in irgendwelchen Control Events rumfrickeln durfte, um das alles anzupassen, wenn er nicht strikt getrennt hat.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
SebE

Registriert seit: 31. Jul 2004
Ort: Chemnitz
316 Beiträge
 
Delphi 7 Personal
 
#35

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:34
OOP bis zum "Gehtnichtmehr"! Delphi ist für mich ein RAD-Tool und OOP ist kein Dogma. Es gibt nun einfach Dinge, die im praktischen Entwickleralltag sinnlos sind. Eine strikte Trennung von GUI und Anwendungslogik ist in Delphi nicht immer zwingend und verhindert manchmal sogar die Übersichtlichkeit und Lesbarkeit des Codes bei kleinen Projekten. Leider habe ich den Link nicht mehr gefunden, aber irgendwer hat mal ein Horrorbeispiel in OOP für ein Hello-Word Programm geschrieben (vielleicht kennt ja hier jemand das Beispiel). Also meine Ansatz: Auslagerung in externe Klassen nur dann wenn es Sinn macht und/oder die Lesbarkeit des Codes verbessert.
(fett von mir)

Der Thread heißt "Trennung von GUI und Logik".
Wenn du uns zeigen kannst, wie man ohne Vererbung diese gewünschte Trennung vollziehen kann, bin ich sofort ruhig.
Bis dahin sage ich: Wieder am Thema vorbei.
Was nützt es dem TE, wenn er es wissen will, oder wirklich benötigt?
Ein Problem wegzureden, löst es nicht.

Zitat:
OOP bis zum "Gehtnichtmehr"!
Ein Muss, wenn du mit C# programmierst!
Sebastian
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.324 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#36

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:35
Nativ wie gesagt mit meiner Library ab Delphi 2010. Das Prinzip dahinter ist aber genauso mit Delphi 7 realisierbar (halt mit einigen Abstrichen bzgl der RTTI und Generics z.B.)

Eingangsbeispiel mal mit meinen DataBindings realisiert im Anhang
Das Beispiel funktioniert bei mir aber nicht. Der Button löst keine Addition aus.

Memory Leaks gibt's auch
Liegt wohl daran, dass im svn nicht die aktuellste version liegt, ich bin gerade dabei neuste Änderungen einzuchecken. Dazu gehört u.a. ActionBinding. Versuchs später oder morgen früh nochmal.

OOP bis zum "Gehtnichtmehr"! Delphi ist für mich ein RAD-Tool und OOP ist kein Dogma. Es gibt nun einfach Dinge, die im praktischen Entwickleralltag sinnlos sind. Eine strikte Trennung von GUI und Anwendungslogik ist in Delphi nicht immer zwingend und verhindert manchmal sogar die Übersichtlichkeit und Lesbarkeit des Codes bei kleinen Projekten. Leider habe ich den Link nicht mehr gefunden, aber irgendwer hat mal ein Horrorbeispiel in OOP für ein Hello-Word Programm geschrieben (vielleicht kennt ja hier jemand das Beispiel). Also meine Ansatz: Auslagerung in externe Klassen nur dann wenn es Sinn macht und/oder die Lesbarkeit des Codes verbessert.
Nicht böse gemeint, aber du gehörst scheinbar auch zu der Sorte Delphi Entwickler, die meint, nur weil man Buttons, Edits und Listboxen aufs Form streuen kann und mitm Doppelklick die nötige Logik ins Event klimpern kann, muss man das auch so machen und alles andere wäre dogmatisch. Natürlich kann man auch nen Hello World Programm over engineeren, aber genau dafür sind nunmal simple Beispiele da. Wer's an sowas nicht lernt, dem brauchste garkein echten Usecase geben.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (19. Aug 2011 um 20:40 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von divBy0
divBy0

Registriert seit: 4. Mär 2007
Ort: Sponheim
1.016 Beiträge
 
Delphi XE2 Professional
 
#37

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:35
Also ich will es unbedingt wissen und benötigen wird man es so oder so...
Marc
9 von 10 Stimmen in meinem Kopf sagen ich bin nicht verrückt, die 10. summt die Melodie von Tetris... | Wenn das die Lösung ist, dann hätte ich gerne mein Problem zurück! | engbarth.es
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
3.541 Beiträge
 
Delphi XE3 Ultimate
 
#38

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:38
Der Thread heißt "Trennung von GUI und Logik".
Wenn du uns zeigen kannst, wie man ohne Vererbung diese gewünschte Trennung vollziehen kann, bin ich sofort ruhig.
Bis dahin sage ich: Wieder am Thema vorbei.
Was meinst Du damit?
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
SebE

Registriert seit: 31. Jul 2004
Ort: Chemnitz
316 Beiträge
 
Delphi 7 Personal
 
#39

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:42
Zitat:
Also ich will es unbedingt wissen und benötigen wird man es so oder so...
Dann hast du die Wahl: zwei Lösungen wurden vorgestellt (mehr kenne ich auch nicht):
- Nativ ohne Framework-Einsatz (mein Code sollte einen Einblick gegeben haben, wo die Knackpunkte liegen)
- "magische Lösung", bei der vieles versteckt wird und das Projekt schön klein bleibt.

Wenn du es unbedingt (aus Bildungsgründen) zu Fuß machen möchtest, schaue dir folgende Pattern an:
Observer, Visitor, Proxy
Sebastian
  Mit Zitat antworten Zitat
Progman

Registriert seit: 31. Aug 2007
Ort: 99974 MHL
695 Beiträge
 
Delphi 10.1 Berlin Starter
 
#40

AW: Trennung von GUI und Logik, wie geht ihr vor?

  Alt 19. Aug 2011, 20:43
Wer schonmal an einem Projekt gearbeitet hat, wo trotz Mockups plötzlich die Entscheider der Meinung war, dass der Workflow für den Benutzer ja so mal garnicht geht und man das ganze doch ganz anders bedienen und darstellen muss, wird geflucht haben, wenn er dann überall in irgendwelchen Control Events rumfrickeln durfte, um das alles anzupassen, wenn er nicht strikt getrennt hat.
Aber was ist mit einem solchen "dreiteiligen" (ich nenns mal so) Programmieren, wenn 1 Woche vor Deadline der Entscheider meint, dass auf der Oberfläche noch einige Bedienelemente sein müssen, die dann Fenster erscheinen lassen, wo der User was eingeben/einstellen kann? In der normalen RAD-Programmierung geht das ruckzuck. Nach diesem "Model" müsste ich alle drei Teile erweitern und zusehen, dass ich die auch exakt wieder verbinde. Resultat wäre doch sicherlich ein Code-Chaos, wo man bei eventuell nötigen Änderungen gar nicht mehr durchblickt
Ich programmiere seit über 25 Jahren und bin der Meinung, dass hier extremst ubers Ziel hinausgeschossen wird. Das riecht verdammt nach OOP-Fetischismus *gg*
Karl-Heinz
Populanten von Domizilen mit fragiler, transparenter Aussenstruktur sollten sich von der Translation von gegen Deformierung resistenter Materie distanzieren!
(Wer im Glashaus sitzt sollte nicht mit Steinen werfen)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:05 Uhr.
Powered by vBulletin® Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2017 by Daniel R. Wolf