AGB  ·  Datenschutz  ·  Impressum  







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

Trennung von GUI und Logik, wie geht ihr vor?

Ein Thema von divBy0 · begonnen am 19. Aug 2011 · letzter Beitrag vom 30. Jan 2018
Antwort Antwort
Seite 1 von 2  1 2      
FredlFesl

Registriert seit: 19. Apr 2011
293 Beiträge
 
Delphi 2009 Enterprise
 
#1

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

  Alt 19. Aug 2011, 21:56
Es muss jeder für sich entscheiden, ob er und sein Umfeld Nutzen davon hat, oder ob er "schludern" (nicht negativ gemeint) kann. Ich vergleich ein Programm oft mit einem Haus... und jeder kennt wohl den Begriff Pfusch am Bau. Aber bei Software meinen viele, dat sieht ja keiner, da kann ich ruhig alles zurechtpfuschen - "läuft ja".
Der Vergleich mit dem Hausbau, also Planung, Vorbereitung, Design, Ausführung ist sehr gut.

Ebenso, wie man ein Bauvorhaben totplanen kann oder sich bei Verwendung der aktuellsten und neuesten Technologie völlig verhaspelt, wird es in der praktischen Softwareentwicklung (betonung auf 'praktisch') eher so sein, das man nicht die allerneuesten Technologien verwenden wird, sondern die, die ihre Praxistauglichkeit über Jahre bewiesen haben.

Ebensowenig wie man rumfrickeln darf (Quick'N Dirty wird mit Teeren'N Federn belohnt), sollte man so lange refaktorisieren, bis man Preise für Schonheit im Code erhält, wenn man dabei Budget, Deadline und die Geduld des Kunden aus den Augen verliert.

Zwei Dinge sind wichtig (in meinen Augen):
Bei der Arbeit werden nur erprobte Techniken und Pattern verwendet, in der R&D-Zeit allerdings sollte man sich ständig weiterentwickeln.
Das Bild hängt schief.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

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

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

  Alt 19. Aug 2011, 22:33
Der Vergleich mit dem Hausbau, also Planung, Vorbereitung, Design, Ausführung ist sehr gut.

Ebenso, wie man ein Bauvorhaben totplanen kann oder sich bei Verwendung der aktuellsten und neuesten Technologie völlig verhaspelt, wird es in der praktischen Softwareentwicklung (betonung auf 'praktisch') eher so sein, das man nicht die allerneuesten Technologien verwenden wird, sondern die, die ihre Praxistauglichkeit über Jahre bewiesen haben.
Ich würde sowas, wie wir in diesem Thread behandeln eher mit nem Fertighaus vergleichen. Einzelne Teile werden getrennt von einander gebaut (GUI, Business Logik, Daten(klassen)) und vor Ort einfach zusammen gesteckt.

Quick'N Dirty wird mit Teeren'N Federn belohnt
Den muss ich mir merken
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

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

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#3

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

  Alt 20. Aug 2011, 00:29
Einzelne Teile werden getrennt von einander gebaut (GUI, Business Logik, Daten(klassen)) und vor Ort einfach zusammen gesteckt.
Ne, da wird nichts getrennt gebaut. Es wird ein zusammenhängender Bauplan gemacht und dann den Gegebenheiten angepasst. Siehe hier :
Delphi-Quellcode:
procedure TfrmSuch.btnZurueckClick(Sender: TObject);
begin
  if not SuchDS.Bof then begin
    SuchDS.Prior;
    ZeigeDaten;
    btnWeiter.Enabled := true;
  end
  else begin
    showmessage ('keine vorhergehenden Daten vorhanden !');
    btnZurueck.SetFocus;
    btnZurueck.Enabled := false;
    btnWeiter.Enabled := true;
  end;
end;
Es geht dabei um eine Datensatz-Suche. An dieser Stelle ist SuchDS völlig unbekannt. ZeigeDaten sieht so aus :

Delphi-Quellcode:
procedure TfrmSuch.ZeigeDaten;
begin
end;
Das ist also quasi Nullnummer. Da geht es ja darum, etwas zu suchen. Manchmal ist man zu weit und muss zurück oder umgekehrt. Das bleibt immer gleich. Egal, um was es geht. Die GUI ist also schon da. Die Logik wird später eben besetzt. Man nennt das auch OOP.
Gruß
Hansa
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#4

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

  Alt 20. Aug 2011, 00:56
Es geht ja aber gerade darum, das zu trennen.

Du kannst Deine gesamten Daten und Zustände in Deiner Datenebene verwalten. Ebenso die Methoden, die die Geschäftslogik darstellen.
Wenn Du Deine Datenebene als Objekt betrachtest, könntest Du z.B. über TFirma.MitarbeiterListe.BefördereMitarbeiter(5) irgendeine Aktion veranlassen.
Dadurch wird der Mitarbeiter gleich noch in das Chefzimmer verschoben und bekommt das doppelte Gehalt. Das wäre dann die Geschäftslogik

So, das Programm an sich funktioniert jetzt schon mal wunderbar.

Jetzt müssen wir noch ein Formular basteln, das die Daten anzeigt und einen Beförderungsknopf erhält.
Das ist auch schnell erledigt.

Nun fehlt noch die Verbindung der beiden Ebenen.
Mit DataBinding kann man eben zur Entwicklungszeit der ListBox die Mitarbeiterliste zuweisen (bestenfalls direkt im Objektinspektor per Aufklappliste) und dem Schalter die Beförderungsmethode.
Letzteres ist u.U. schwieriger, da ja manchmal bestimmte Parameter übergeben werden müssen. DAS muss man dann sicher per Code regeln.
Aber sonst muss es in der GUI nicht mehr viel Quelltext geben.

Also ich habe Blut geleckt!


EDIT:
Und wenn man mal auf die Idee kommt, das Projekt als Konsolenanwendung, als Webanwendung oder für FireMonkey lauffähig zu machen, muss man grundsätzlich nur die GUI ersetzen. Alles weitere bleibt in der Datenebene unverändert. Nur der Zugriff von außen wird verändert.
Das ist eben bei einer "klassischen Delphi-Anwendung" so nicht möglich. Ebenso nicht spätere gravierende Umstrukturierungen.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli (20. Aug 2011 um 01:01 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

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

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

  Alt 20. Aug 2011, 00:57
Einzelne Teile werden getrennt von einander gebaut (GUI, Business Logik, Daten(klassen)) und vor Ort einfach zusammen gesteckt.
Ne, da wird nichts getrennt gebaut. Es wird ein zusammenhängender Bauplan gemacht und dann den Gegebenheiten angepasst. Siehe hier :
Delphi-Quellcode:
procedure TfrmSuch.btnZurueckClick(Sender: TObject);
begin
  if not SuchDS.Bof then begin
    SuchDS.Prior;
    ZeigeDaten;
    btnWeiter.Enabled := true;
  end
  else begin
    showmessage ('keine vorhergehenden Daten vorhanden !');
    btnZurueck.SetFocus;
    btnZurueck.Enabled := false;
    btnWeiter.Enabled := true;
  end;
end;
Es geht dabei um eine Datensatz-Suche. An dieser Stelle ist SuchDS völlig unbekannt. ZeigeDaten sieht so aus :

Delphi-Quellcode:
procedure TfrmSuch.ZeigeDaten;
begin
end;
Das ist also quasi Nullnummer. Da geht es ja darum, etwas zu suchen. Manchmal ist man zu weit und muss zurück oder umgekehrt. Das bleibt immer gleich. Egal, um was es geht. Die GUI ist also schon da. Die Logik wird später eben besetzt. Man nennt das auch OOP.
Sorry, aber sowas geht echt ma garnicht, wenn man voneinander trennen möchte.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (20. Aug 2011 um 01:02 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#6

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

  Alt 20. Aug 2011, 01:10
Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
SebE

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

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

  Alt 20. Aug 2011, 01:23
Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.
(fett durch mich)

Im Allgemeinen gilt: je mehr Abstraktionen, desto flexibler die Anwendung (die Kommunikation).
Ob der Code dabei übersichtlich bleibt, ist fraglich.
Man kann auch Abstraktionen einführen, die wenig Sinn ergeben oder einfach nicht hilfreich sind.

Klar hat man irgendwo Bindungen. Diese sollten aber - wenn möglich - an "festen" Ort (Controller) plaziert werden und nicht dort, wo am ehesten Änderungen stattfinden (GUI, gefolgt vom Model).

Ein Muss ist auf jeden Fall, eine Abstraktion der GUI aus Sicht des Models, dieses darf die View nicht kennen.
Anders herum ist es vllt nicht immer notwendig, aber "schöner", wenn man eine zusätzliche Schicht hat (Controller).
Denken wir einmal an die Überarbeitung (Refactoring) unserer Business-Objekte (Schnittstellen "verschönern"): Hier wäre es gut, wenn man die GUI belassen kann, wie sie ist.

@Hansa:
Sorry, ich habe deinen Beitrag leider nicht verstanden (ich erkenne an deinem Code-Schnipsel weder OOP, noch wird mir eine Art Ironie ersichtlich).
Ich erkenne nur, dass hier nicht getrennt werden wollte.
Sebastian

Geändert von SebE (20. Aug 2011 um 01:28 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

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

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

  Alt 20. Aug 2011, 01:31
Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.
Ich argumentiere ja für MVVM und da kennt das Form garnix, es hat Anzeige Controls, fertig. Wenn man Business Logik ohne den Ablauf über die GUI designed, kann man sie auch ohne die GUI Testen. Du kannst einfach testen, ob diese oder jene Eigenschaft so ist, wie du es erwartest, wenn du einen Wert setzt. Diese werden letztlich über die GUI präsentiert. Aber das Programm wäre auch komplett ohne Oberfläche lauffähig.

wenn man voneinander trennen möchte.
Was geht nicht ??
- Logik direkt ins Event kodiert.
- abhängig von der Logik werden wiederum Controls beeinflusst; zwar im kleinen Rahmen in diesem Beispiel, läuft trotzdem dem zuwider, was ich vor dem Quote schrieb.
- Feedback direkt über ShowMessage ausgegeben.

Diese Methode allein ist nicht unittestbar um zum Beispiel zu schauen, ob das mit dem nicht weiter zurück blättern klappt, wenn man schon vorne ist.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

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

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
2.059 Beiträge
 
Delphi 12 Athens
 
#9

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

  Alt 20. Aug 2011, 12:12
[Edit]
sowas ähnliches was neo4a sagt... nur ohne die quellen...und nur binding mag ich nicht ganz so...
habe da in Javafx wirklich schlechte Erfahrungen mit gesammtelt.
[/Edit]
Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.
Ich sehe das so, in einem MVC müssen die 3 Programmteile mit einander informationen austauschen ohne sich zu kennen.

Andererseits will ich nicht wirklich Zwischenebenen einbauen die jeweils 2 oder alles Teile Kennen und quasi eine Postkasten(Messagequeue) Funktion erfüllen.


Die einfachste möglichkeit sehe ich also darin IControler, IView und IModel zu definieren und jeweils gegenseitig zu registrieren.

Wichtig dabei ist das es NICHT ein IView, IControler und IModel gibt sondern das es durchaus möglich ist das ich weiter aufteile und ableite
IStammdatenView, IStammdatenControler, IStammdatenModel
IBewegungsdatenView, IBewegungsdatenControler, IBewegungsdatenModel

usw.

Klassen die diese Interfaces implemtieren lassen sich dann einfach einander als Interface Registrieren egal was am ende wirklich da bedient wird.

Es ist dann auch egal ob das Formular Spaghetticode enthält, weil für die Betrachtunge der Gesammtaufgabe braucht man sich nur an den Interfacedefinition orientieren und im Kleinen ist Spaghetti code ertragbar(verzicht auf binding).

Leider habe ich noch kein Programm gesehen das auf diese Art und weise entwickelt wurde...
außer eines...aber da wurde kein Interface benutzt sondern jede ebene jedes Anwendungsfalles mit einem Webservice dargestellt(StammdatenViewWebservice,StammdatenCon trolerWebservice,StammdatenModelWebservice) und SOAP legt die Zugriffsmöglichkeiten ja auch ziemlich gut fest ohne das man sich gegenseitig ganz genau kennen muss ähnlich wie Interface...man muss eben nur die Adresse wissen.
Andreas
Nobody goes there anymore. It's too crowded!

Geändert von QuickAndDirty (20. Aug 2011 um 12:21 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von divBy0
divBy0

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

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

  Alt 20. Aug 2011, 12:42
Binding kommt ja erst mit XE2, DSharp von Stevie funktioniert erst ab D2010 so einigermaßen wegen den Generics. Ich hab jetzt noch nicht mit Google gesucht, aber gibt es denn weitere Binding-Komponenten?

Wenn ich das richtig verstehe konnte man bisher eigentlich nur mit MVC eine Trennung durchführen.

DSharp gefällt mir echt gut und ich experimentiere damit jetzt etwas rum.
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
Antwort Antwort
Seite 1 von 2  1 2      


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:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:27 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz