GUI-Anwendung - Strukturierung des Programms

[nun_ja]

Hi,

bin dabei ne GUI-Anwendung mit Java zu schreiben und frage mich, wie ich das am besten strukturiere:

-Jedes Fenster als Klasse wäre ja schonmal sinvoll.

-Sollte die Anwendung selbst ne statische Klasse als Kern haben, deren Funktionen von Event Handlern der Fenster angesprochen werden und die die Aufgaben weiter delegieren?

Um das vll noch mal abstrahiert darzustellen: Wie strukturiere ich GUI und den Programmkern, bzw. wie verknüpfe ich beide am besten?

Für Links, Erklärungen oder gerne auch Beispiele wäre ich dankbar!

mfg
Fabian

[Marc Reichelt]

Hallo,

Um das vll noch mal abstrahiert darzustellen: Wie strukturiere ich GUI und den Programmkern, bzw. wie verknüpfe ich beide am besten?

Für Links, Erklärungen oder gerne auch Beispiele wäre ich dankbar!

Ich halte es generell für gut, Gruppen von Funktionalitäten in JPanels zu gruppieren - und nicht das ganze Fenster (JFrame).
Das hat vor allem den Vorteil, dass man nachher flexibler ist, wenn die GUI-Gruppen später beispielsweise nicht ein ganzes Fenster füllen sollen, sondern z. B. Bestandteile von anderen GUI-Gruppen sind.
Ein sehr einfaches Beispiel habe ich auch parat.

Code für Datei "Program.java":

import javax.swing.JFrame;  
  
public class Program {  
  
 public static void main(String[] args) {  
  JFrame f = new JFrame("Fenster");  
  f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);  
  
  f.add(new Configuration());  
  
  f.setSize(300, 100);  
  
  f.setVisible(true);  
 }  
  
}

Code für Datei "Configuration.java":

import javax.swing.JButton;  
import javax.swing.JPanel;  
import javax.swing.JTextField;  
  
public class Configuration extends JPanel {  
  
 public Configuration() {  
  this.add(new JButton("eins"));  
  this.add(new JButton("zwei"));  
  this.add(new JTextField("drei"));  
 }  
  
}

Natürlich kann man das auch schöner realisieren (beispielsweise muss die Klasse "Configuration" ja selbst nicht von JPanel abgeleitet sein, sondern kann dieses einfach nur über eine Methode zurückliefern), aber das grundsätzliche Prinzip ist klar. Wenn diese drei (gruppierten) Konfigurationselemente später nicht in ein JFrame, sondern z. B. in einen Dialog oder sogar in ein anderes JPanel übernommen werden sollen, braucht man den Code der Klasse Configuration nicht anzufassen.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[nun_ja]

Vielen Dank euch beiden!
Hab schon ein wenig im weiter recherchiert, habt mir wirklich geholfen!

mfg
fabian

[Frank (no reg)]

Nun ja, ...

MVC (Model-View-Controller) bietet sich als allgemeines Design-Pattern an. Ein Singleton als "Applikationsklasse" führt gemeinsame Funktionalitäten / Services zusammen. Für die Verknüpfung von MVC Elementen kannst du ein Command-Pattern einsetzen (alle möglichen Aktionen und Handlungen als Commands abstrahieren) und die Ausführung dann kaskadierend im Controller beginnen lassen.

Für jedes Fenster eine eigene spezifische Klasse zu schreiben, ist vielleicht etwas unflexibel. Wie Marc Reichelt schon erwähnte, kombiniere Controls zu wiederverwendbaren logischen Einheiten, die immer einen bestimmten Zweck oder eine Funktion erfüllen (Suchformular, Navigation ...). Die "grossen" Fenster kannst du dann dahingehend flexibilisieren, dass sie vorher entwickelte Controls/Panels (dynamisch) verwalten, anordnen und bedienen können.

"Software Design Patterns" gebe ich dir mal noch als allgemeines Stichwort mit. Im Internet und auch auf Papier gibt es genügend zu lesen, welche Pattern sich besonders gut oder schlecht für bestimmte Zwecke eignen. (Patterns == Best Practices).

Ciao, Frank

[Hamstar]

Ich habe ja von Java keine Ahnung, aber diese "Fachwörter" haben mich doch ein wenig grau werden lassen. Was wurde da erörtert? Kannst Du das mal in allgemeinverständlichen Wörtern darlegen?

Hintergründlich steht ja ganz vermutlich ein RDBMS mit einigen "Entitäten", die ja irgendwie bearbeitet werden. Das würde ich ja schon verstehen, aber "Singletons" und "Patterns" machen mich ein wenig nervös.

Webverweise, die über Java-Slang hinausgehen, wären auch nicht schlecht.

BTW - "Best Practices" lässt mich vor Wut im Dreieck springen.   ;)

[Frank (no reg)]

Hallo Ham-star!

Die Welt geht hinter dem Horizont von relationalen Datenbank übrigens noch weiter ;) *scnr*. Die andere Seite hat aber ein analoges Problem :)

Für die Implementierung von Software haben sich im Laufe der letzten Jahrzehnte immer wieder ähnliche Schemen abgezeichnet, wie *ähnliche* Aufgabenstellungen umgesetzt worden sind, quasi-standar*t*s. Mittlerweile unter dem Begriff "Patterns" durchaus geläufig. Solche Patterns gibt es auf verschiedenen Ebenen:

Architektur z.b. SOA, REST
Design z.b. MVC
Implementierung z.b. Composite, Flyweight, Commands

Es gibt dann noch die Unterklassifizierung z.b. nach Strukturellen ~ und Verhaltens-Patterns.

Und Patterns sind plattformunabhängig. Ein MVC oder Singleton kannst du mit C++, Delphi, .Net oder Java hochgradig gleich (vom Konzept) umsetzen.

Was erörtert worden sein sollte: Wie modelliere ich eine Presentationsschicht (in objektorientierter Weise), welche bestehenden *elaborierten* Praktiken gibt es für soetwas? Was hat sich durchgesetzt, was ist stabil, was verspricht die grössten Erfolgschancen.

Eine Softwareanwendung ist heutzutage im Durchschnitt eher komplex, die einfachen Terminal-Datenbankeingabe-Frontends von früher werden durch Software abgelöst, die nicht-triviale Prozesse abbildet (z.b. einen Fragebogen anlegen). Aus bestehenden Fragen auswählen, bei Bedarf gleich neue Fragen anlegen, ne Vorschau und das Speichern oder Verwerfen (Undos etc) ... Solche Dinge müssen irgendwie koordiniert werden. Da tauchen dann solche Fragen auf, wie: Verpacke ich den ganzen Prozess in einen Wizard oder in ein MDI (Multiple Document Interface) oder in Tabbed Dialogs (Kartenreiter-Dialoge) usw.

Links zum Thema Patterns:
http://de.wikipedia.org/wiki/Model_View_Controller
http://www.patterndepot.com/put/8/JavaPatterns.htm

James W Cooper und Erich Gamma sind die Gurus auf diesem Gebiet.

Noch Fragen (nachdem du dich selbständig belesen hast?)? ;)

Ciao, Frank

[Daniel Thoma]

Hallo Frank,

Architektur z.b. SOA, REST

Das sind wohl eher allgemeinere Architekturkonzepte im Falle von SOA vielleicht sogar ein Organisationskonzept ;)

Design z.b. MVC

MVC ist ganz klar ein Architekturmuster, da es eine Architekturlösung für ein ganz spezielles Problem, nämlich die Realisierung einer GUI-Anwendung beschreibt.

Implementierung z.b. Composite, Flyweight, Commands

Das sind klassische Entwurfsmuster wie von Gamma und Co. eingeführt.

Es gibt dann noch die Unterklassifizierung z.b. nach Strukturellen ~ und Verhaltens-Patterns.

Die taugt vor allem für Designpatterns und wurde ja auch dafür eingeführt, eine Lösung auf Architekturebene umfasst ja idR. mehrere oder alle diese Aspekte.

Und Patterns sind Plattformunabhängig. Ein MVC oder Singleton kannst du mit C++, Delphi, .Net oder Java hochgradig gleich (vom Konzept) umsetzen.

Implementierungsmuster sind das dann nicht mehr, ich habe allerdings auch noch keine nennenswerten Implementierungsmuster gesehen. Typische Codeschnipsel in einer Sprache könnte man wohl so bezeichnen.

James W Cooper und Erich Gamma sind die Gurus auf diesem Gebiet.

Nun Gamma und Co. haben diese Muster eingeführt. Cooper musste ich erstmal suchen, die Bücher scheinen im wesentlichen dieses klassischen Muster zu behandeln. Bücher dieses Typs gibt es mittlerweile unzählige, neue Konzepte findet man da eher selten, mir ist jedenfalls noch nicht viel begegnet.

Grüße

Daniel

[Frank (no reg)]

Hi,

da du selbst eine sehr unscharfe Abgrenzung zwischen den Begriffen "Entwurfsmuster", "Designpatterns", "Architekturmuster", "Implementierungsmuster" verwendest, gibst du mir sicher Recht, dass die Klassifizierung doch sehr subjektiv ist.

Und wenn es dich glücklich macht, MVC als Architekturmuster und Composites etc als "klassische Entwurfsmuster" zu betrachten, schön für dich.

Und Patterns sind Plattformunabhängig. Ein MVC oder Singleton kannst du mit C++, Delphi, .Net oder Java hochgradig gleich (vom Konzept) umsetzen.
Implementierungsmuster sind das dann nicht mehr ...

Wo ist da der Zusammenhang?

Ciao, Frank

[Daniel Thoma]

Hallo Frank,

da du selbst eine sehr unscharfe Abgrenzung zwischen den Begriffen "Entwurfsmuster", "Designpatterns", "Architekturmuster", "Implementierungsmuster" verwendest, gibst du mir sicher Recht, dass die Klassifizierung doch sehr subjektiv ist.

Entwurfsmuster ist lediglich die Übersetzung von "Designpattern". Ich verwende eigentlich keine unscharfe Abgrenzung, und wenn die Abgrenzung unscharf ist, dann zwischen Architektur- und Entwurfsmuster, Implementierungsmuster ist aber ganz klar unterscheidbar. Ein Implementierungsmuster ist Sprachabhängig und baut nicht nur auf allgemeinen OO-Konzepten auf.
Die von Dir genannten Muster (Composite usw.) Designpatterns oder Entwurfsmuster zu nennen, ist schon allein deshalb naheliegend, weil sie die Schöpfer der Begriffs nunmal so genann haben... Gamma beschreibt in seinem Designpatterns-Buch auch, was er unter einem Designpattern versteht und MVC passt da nicht drunter. Möglicherweise verwendet er es sogar als Beispiel dafür.

Und Patterns sind Plattformunabhängig. Ein MVC oder Singleton kannst du mit C++, Delphi, .Net oder Java hochgradig gleich (vom Konzept) umsetzen.
Implementierungsmuster sind das dann nicht mehr ...
Wo ist da der Zusammenhang?

Der Zusammenhang ist, dass Du kurz darüber die Muster (Composite etc.) als Implementierungsmuster bezeichnest, denen Du hier Plattformunabhängigkeit attestierst. Das ist eben schlicht falsch, weil es weder mit den Begrifflichkeiten, wie sie durch das Gamma-Buch eingeführt wurden und so üblich sind, übereinstimmt.

Grüße

Daniel

[Hamstar]

James W Cooper und Erich Gamma sind die Gurus auf diesem Gebiet.

Noch Fragen (nachdem du dich selbständig belesen hast?)? ;)

Kommt man da nicht einfach mit XSLTransformationen, die redudelt adäquat ebgelegt werden?

[Hamstar]

Kommt man da nicht einfach mit XSLTransformationen, die redudelt adäquat ebgelegt werden?

"gerudelt"

[Hamstar]

Eine Softwareanwendung ist heutzutage im Durchschnitt eher komplex, die einfachen Terminal-Datenbankeingabe-Frontends von früher werden durch Software abgelöst, die nicht-triviale Prozesse abbildet (z.b. einen Fragebogen anlegen). Aus bestehenden Fragen auswählen, bei Bedarf gleich neue Fragen anlegen, ne Vorschau und das Speichern oder Verwerfen (Undos etc) ... Solche Dinge müssen irgendwie koordiniert werden. Da tauchen dann solche Fragen auf, wie: Verpacke ich den ganzen Prozess in einen Wizard oder in ein MDI (Multiple Document Interface) oder in Tabbed Dialogs (Kartenreiter-Dialoge) usw.

Noch Fragen (nachdem du dich selbständig belesen hast?)? ;)

Die o.g. Beispiele sind doch "einfach" (um das Wort trivial zu vermeiden). Ich kann mir vorstellen, dass man für Spezialsoftware (Grafikanwendungen, Spiele, "Herumhühnern auf sehr heterogenen Datenstrukturen" etc.) sowas braucht, aber ansonsten?

[Daniel Thoma]

Hallo nun_ja,

Ein wirkliches Rezept für Architektur gibt es nicht. Es gibt ein paar gängige Konzepte, aber nicht sehr viel mehr.

Zu empfehlen ist:

• GUI und Funktionalität trennen.
• Aufgabenbereiche durch Modularisierung trennen.

Du hast also Klassen für einzelne Bereiche der GUI (Am Beispiel einer IDE z.B. für Editor, Projektverwaltung, Debugger) und in einer Schicht darunter Klassen, die die Funktionalität hinter der GUI und das Datenmodell bzw. die Datenmodelle (in einer komplexen Anwendung kann es durchaus Sinnvoll sein, für verschiedene Aufgaben getrennte, oder nur sehr Schwach voneinander abhängende Datenmodelle zu haben) realisieren.

Mit MVC sollte man vorsichtig sein. Oft wird MVC so umgesetzt, dass es ein Modell, einen Controller und mehrere Views gibt. Damit läuft man aber in Gefahr, dass man die gesamte Ablauflogik im Controller zentralisiert und sich damit die Flexibilität der Architektur zerschießt.
MVC ist meines Erachtens zumindest bei Desktopanwendungen, die idR. über so etwas wie einen festen Arbeitsablauf nicht verfügen, nur als lokale Architektur geeignet (im Falle des IDE-Beispiels also z.B. jeweils einzeln für den Editor, den Debugger usw.) und nicht als globale Architektur.

Wenn Du etwas über Architektur von (größeren) Desktopanwendungen lernen willst, schaust Du Dir am besten mal eine von innen an. Die Java IDEs (Netbeans, Eclipse) eignen sich da ganz gut. Beide bieten meines Wissens auch das Framework an, auf dem sie jeweils selbst basieren.
Für eine kleinere Anwendung mag das allerdings etwas übertrieben sein.

Grüße

Daniel

[Hamstar]

Um das vll noch mal abstrahiert darzustellen: Wie strukturiere ich GUI und den Programmkern, bzw. wie verknüpfe ich beide am besten?

Wenn Du eine normale Anwendung schreibst, also nicht mit Spezialsoftware hantierst, dann machst Du am besten folgendes:
1.) die DB designen
2.) den Datenzugriff (SQL) entweder als so genannte stored procedure im RDBMS ablegen oder modularisiert (d.h. absolut vom UI-Code getrennt) im Code (Ersteres ist vorzuziehen)
Dann hast Du das System geschrieben, d.h. alles, was Deine Anwendung können soll, kann Sie schon. Aber nur "per Hand" im Query-Tool Deines RDBMS. das reicht uns noch nicht, also:
3.) UI-Code schreiben, schön modularisiert und zwar "parallel" zum Datenzugriffscode. Also ich meine so "1:1", ach ich weiss jetzt auch nicht wie ichs schreiben soll.   ;)

Es gibt objektorientierte Ansätze fürs UI, aber ich lass davon die Finger weil sich m.E. eine "normale" Anwendung (viele Transaktionen aufs RDBMS) mit Objektorientiertheit beisst.

Aber "it depends", schreibst Du Grafikprogramme oder Editoren oder Tabellenkalkulationen, also Anwendungen die "UI-komplex" sind, dann kommst Du am Verständnis dessen was Franky so geschrieben hat, nicht vorbei. Viel Spass!   ;)

[Johannes Zeller]

1.) die DB designen

Außer dir hat keiner von einer DB gesprochen. Gegen deine RDBMS-Fixiertheit wäre es vielleicht mal eine gute Idee, einen Blick über den Tellerrand zu werfen und zu erkennen, dass es auch noch andere Arten von Programmen gibt.

Johannes

[Hamstar]

1.) die DB designen

Außer dir hat keiner von einer DB gesprochen. Gegen deine RDBMS-Fixiertheit wäre es vielleicht mal eine gute Idee, einen Blick über den Tellerrand zu werfen und zu erkennen, dass es auch noch andere Arten von Programmen gibt.

DB = Datenbasis, ein Programm ohne DB ist wie ein Johannes ohne Zeller. Wenn nicht noch schlimmer.

[Daniel Thoma]

Hallo Hamstar,

Du scheinst zentralisierte, unabhängige Verwaltungsanwendungen zu bauen. Das ist natürlich relativ tivial.
Es gibt ein gut strukturierbares Datenmodell mit einfacher Verhaltenslogik, dass man praktisch komplett in die DB packen kann. Die (Web-)GUI dazu bastelt man dann irgendwie mittels geeigneter Technologie drüber.

Wenn man kompliziertere Abläufe und verteilte Systeme hat (z.B. weil man eben Systeme für verschiedene Aufgaben verknüpfen muss), wird das schon komplizierter.
Die Organisation der GUI wird bei Desktopanwendungen auch nochmal komplizierter, weil es oft keine einfachen Abläufe mehr gibt sondern der Anwender praktisch beliebig zwischen verschiedenen Aufgaben wechseln kann.

Eine relationale Datenbank unter dem System braucht man sowieso überhaupt nur dann, wenn es darum geht, Daten zu verwalten. Das hat "nun_ja" aber noch nicht mal gesagt.

Grüße

Daniel

[Hamstar]

Du scheinst zentralisierte, unabhängige Verwaltungsanwendungen zu bauen. Das ist natürlich relativ tivial.

LOL - aber nicht, wenn Du auf DBs mit bspw. 50 übelst verzeigerten Tabellen sitzt mit entsprechend komplexem Datenzugriff.

Wenn man kompliziertere Abläufe und verteilte Systeme hat (z.B. weil man eben Systeme für verschiedene Aufgaben verknüpfen muss), wird das schon komplizierter.

Es sind verteilte Systeme.

Die Organisation der GUI wird bei Desktopanwendungen auch nochmal komplizierter, weil es oft keine einfachen Abläufe mehr gibt sondern der Anwender praktisch beliebig zwischen verschiedenen Aufgaben wechseln kann.

Die Navigation macht den Braten nicht fett und somit nicht den Hauptunterschied zur o.g. transaktionalen Datenbankanwendung.
Es ist - wie auch schon an anderer Stelle angeführt - die unterschiedliche "UI-Intensität", die bspw. bei einer Textverarbeitung Komplexität bedingt (und damit wohl auch solche für mich eher lustigen Sachen wie design patterns, best practises und Entwicklungsmodelle wie RAD etc.).

Eine relationale Datenbank unter dem System braucht man sowieso überhaupt nur dann, wenn es darum geht, Daten zu verwalten. Das hat "nun_ja" aber noch nicht mal gesagt.

Tabellenbasierte Datenbasen sind etwas sehr Normales, aber Du hast recht, es gibt (sogar hier im Forum ;) sehr fähige Windows-Entwickler ohne besondere DB-Kenntnisse.

[Frank (no reg)]

Hamstar, ich grüsse dich!

Höre doch bitte mal um deiner Horizonterweiterung Willen auf, alles auf
relationale Datenbanken zu projezieren/reduzieren.

Ob da irgendwo eine Datenbank drunter sitzt ist für das Gesamtbild vom Softwaresystem nur sekundär interessant. Die kann man dann mit Stored Procedures abstrahieren (und siehe da, da haben wir ein "Pattern", es wird und wurde schon oft so gemacht, hat viele Vorteile und sich in der Praxis behauptet) ...

Aber nehmen wir einfach mal eine Software, die du bestimmt selbst sehr gut kennst: Den MS SQL Query Analyzer. Auf den ersten Blick eine nicht allzukomplex erscheinende Software, oder? Ein Fenster, in dem man kleinere Fensterchen öffnen kann, was eingeben kann und dann an die DB zum Ausführen schicken kann, oder? Da geht es schon los, der Ausführen-Button muss sich mit den Fenstern koordinieren, dass immer der Inhalt des momentan aktiven Fensters ausgeführt wird. Über das Menü kann eingestellt werden, wie die Ausgabe erfolgen soll (Grid, Text, File). Die jeweils aktuell gewählte Einstellung muss irgendwo aufbewahrt werden und auf das zurückkehrende Ergebnis angewendet werden. Dann nehmen wir noch den Objektexplorer dazu, er existiert parallel, von ihm aus können per Kontextmenü neue Fensterchen mit oder ohne Inhalt, verbunden oder unverbunden zur Datenbank erzeugt werden. Das alles, die Fensterchen und auch die ganzen Dialoge für Voreinstellungen müssen ja irgendwie miteinander koordiniert werden, oder nicht? Und auch implementiert werden. Eine "Script as create to new window" Funktion ist da schon nicht mehr als trivial für sich anzusehen, sie involviert mehrere Vorgänge (abfragen von MetaInformationen, erzeugen des Scripts) und auch  mehrere GUI-Elemente ... weisst du jetzt besser worum es geht?

So nah an Datenbanken und doch soweit entfernt. Und hier zählt kein vorher hübsch entwickeltes Datenbankmodell oder Datenzugriff mit Stored Procedures.

Und dafür gibt es eben etablierte Vorgehensweisen, Patterns genannt :) Und wie du siehst, gibt es Patterns auch im Datenbankbereich: Abstrahierung via SPs oder Nested Sets zum Bleistift.

Vielleicht solltest du selbst zum Spass mal versuchen eine Software zu schreiben, wo du nicht nur den Datenbankkram machst sondern das Gui implementierst.

Gruss, Frank

[Hamstar]

Höre doch bitte mal um deiner Horizonterweiterung Willen auf, alles auf
relationale Datenbanken zu projezieren/reduzieren.

Moment, SW unterstützt zwischenmenschliche Kooperation, also die Wirtschaft, benötigt Datenhaltung, Datenhaltung repreäsentiert oft verschiedene reale Objekte und ist darum typischerweise relational (nicht zu verwechseln mit RDBMSen).

Aber nehmen wir einfach mal eine Software, die du bestimmt selbst sehr gut kennst: Den MS SQL Query Analyzer. Auf den ersten Blick eine nicht allzukomplex erscheinende Software, oder? Ein Fenster, in dem man kleinere Fensterchen öffnen kann, was eingeben kann und dann an die DB zum Ausführen schicken kann, oder? Da geht es schon los, der Ausführen-Button muss sich mit den Fenstern koordinieren, dass immer der Inhalt des momentan aktiven Fensters ausgeführt wird.

Ich habe mal einen "MS SQL Query Analyzer Light" selbst geschrieben (Webapplikation), das Ausführen veschiedener Abfragen habe ich über verschiedene Browserfenster, die den Sicherheitskontext erbten, realisiert.

Über das Menü kann eingestellt werden, wie die Ausgabe erfolgen soll (Grid, Text, File). Die jeweils aktuell gewählte Einstellung muss irgendwo aufbewahrt werden und auf das zurückkehrende Ergebnis angewendet werden. Dann nehmen wir noch den Objektexplorer dazu, er existiert parallel, von ihm aus können per Kontextmenü neue Fensterchen mit oder ohne Inhalt, verbunden oder unverbunden zur Datenbank erzeugt werden. Das alles, die Fensterchen und auch die ganzen Dialoge für Voreinstellungen müssen ja irgendwie miteinander koordiniert werden, oder nicht?

Na gut, bei Objektexplorer und Kontextmenü fängt bei mir langsam die Spezialsoftware an.   ;)

Und auch implementiert werden. Eine "Script as create to new window" Funktion ist da schon nicht mehr als trivial für sich anzusehen, sie involviert mehrere Vorgänge (abfragen von MetaInformationen, erzeugen des Scripts) und auch  mehrere GUI-Elemente ... weisst du jetzt besser worum es geht?
So nah an Datenbanken und doch soweit entfernt. Und hier zählt kein vorher hübsch entwickeltes Datenbankmodell oder Datenzugriff mit Stored Procedures.

Hey, danke für die Erklärungen, ich ahne um was es geht. Habe selbst mal vor Urzeiten ein Blackjack-Programm geschrieben, das war auch frickelig (habe es nicht ganz fertig bekommen, es gab Probleme mit dem mehrfachen Splitten ;).

Ja, richtig, ich habe die Frickelsoftware schon ein wenig vergessen bzw. selbst nie professionell entiwckelt. Gut, da braucht man petterns, OK.

BTW - Frickelsoftware beisst sich ein wenig mit Webapplikationen, oder?

Und dafür gibt es eben etablierte Vorgehensweisen, Patterns genannt :) Und wie du siehst, gibt es Patterns auch im Datenbankbereich: Abstrahierung via SPs oder Nested Sets zum Bleistift.

Ja, ja, ich hatte doch schon angedeutet verstanden zu haben, dass man für coole, frickelige Spezialsoftware anscheinend patterns und so benötigt.

Vielleicht solltest du selbst zum Spass mal versuchen eine Software zu schreiben, wo du nicht nur den Datenbankkram machst sondern das Gui implementierst.

Danke für die Erläuterungen!

[Frank (no reg)]

Ach Hamstar, du hängst an deiner Datenbank-Welt wie die Maus am Käse.

Ja, richtig, ich habe die Frickelsoftware schon ein wenig vergessen bzw. selbst nie professionell entiwckelt. Gut, da braucht man petterns, OK.
Ja, ja, ich hatte doch schon angedeutet verstanden zu haben, dass man für coole, frickelige Spezialsoftware anscheinend patterns und so benötigt.

Quatsch, coolness oder specialness hat damit nichts zu tun. Stabilität und geeignete Funktionalität schon. Ausserdem, verwendest du gängige Patterns hast du eine gute Basis für jeden Pattern-kennenden Programmierer, sich schnell in deiner Software zurechtzufinden. Ein fähiger Entwickler wird sehr schnell erkennen, welche Patterns eingesetzt worden sind und kann daraus seine Schlüsse ziehen, wo er nach Bedarf schrauben kann/darf/muss, auch wenn er ursprünglich deiner Software wie ein Fremder gegenübersteht.

BTW - Frickelsoftware beisst sich ein wenig mit Webapplikationen, oder?

Wo du frickelst ob in einer Webapplikation oder einer "Desktop"applikation, ist absolut wurst. :)

Und du kannst beruhigt sein, es gibt ebensoviele OO-"Software"-Entwickler, die ihre Weltvorstellung auf alles, insbesondere relationale Datenbanken anwenden wollen.

Da du so gern "frickelst" ... hiessest du in deinem früheren Leben mal "Lude" hier im Forum (und wenn, dann möchtest du es bestimmt niemanden wissen lassen)?

Ciao und guten Morgen ;), Frank

[Hamstar]

Und du kannst beruhigt sein, es gibt ebensoviele OO-"Software"-Entwickler, die ihre Weltvorstellung auf alles, insbesondere relationale Datenbanken anwenden wollen.

Relationale Datenbanken sind selbstverständlich, wenn richtig designt (eigentlich auch wenn falsch designt ;), objektorientiert. Nicht empfehlenswert sind allerdings solche Sachen wie bspw. für jede Tabelle (oder Tabellengruppen, aber schon eine bessere Idee) eine Klasse (Klassen) zu hegen und pflegen oder auch objektorientierter DB-Zugriff (Man stelle sich vor: Schemaabfragen bauen Objekte auf, massiver Traffic, Riesenoverhead, aber schon gesehen, sowas gibt es LOL).

Versuche mal den Unterschied zwischen so genannten Webapplikationen und Spezialsoftware(TM) zu verstehen, Erstgenannte sind einfach, d.h. es gibt keinen besonderen Bedarf für einen ideologisch geprägtem Überbau. SSW(TM) wie z.B. Photoeditoren, die eigentlich nur einen Datensatz (Indexdaten+BLOB in meiner Hamster-Sprache) bearbeiten, dafür aber brutalstmögliche Features bieten, anscheinend nicht. Gut, prima, das ist die Lernnachricht für mich, danke nochmals!

[Daniel Thoma]

Hallo Hamstar,

LOL - aber nicht, wenn Du auf DBs mit bspw. 50 übelst verzeigerten Tabellen sitzt mit entsprechend komplexem Datenzugriff.

Übelst verzeigert ist natürlich nicht immer ein Qualitätsmerkmal eines DB-Designs ;) aber abgesehen davon ist das eine eher lokale Problematik. Natürlich bedarf es etwas Abstraktionsvermögen, ein brauchbares DB-Design zu entwerfen und komplexe Abfragen zu realisieren. Aber man muss nie über die DB hinausdenken.

Es sind verteilte Systeme.

Die DB ist vielleicht verteilt. Aber was ich meinte, wären Systeme, die bspw. ein Buchhaltung, ein Wahrensystem und eine Fertigungssteuerung verknüpfen. Da hast Du plötzlich mehrere Datenbanken in irgend welchen Teilsystemen, Transaktionssicherheit und Konsistenz der Daten ist nicht mehr im wesentlichen mit "das macht ja die DB" erledigt, und man kann ganz sicher nicht mehr alle Funktionalität in Stored Procedures abhandeln, weil man Abläufe hat, die nicht direkt an irgend welchen Datenbeständen hängen, sondern irgendwo darüber liegen.

Die Navigation macht den Braten nicht fett und somit nicht den Hauptunterschied zur o.g. transaktionalen Datenbankanwendung.

Den GUI-Teil der Anwendung macht sie sehr wohl fett. Deine DB handelt Dir ja maximal den Modell und Funktionalitätsteil Deiner Anwendung ab.

Es ist - wie auch schon an anderer Stelle angeführt - die unterschiedliche "UI-Intensität", die bspw. bei einer Textverarbeitung Komplexität bedingt (und damit wohl auch solche für mich eher lustigen Sachen wie design patterns

Entwurfsmuster sind generell interessant, um saubere OO-Entwürfe zu machen. (Mache davon womöglich sogar für den Entwurf von DB-Designs...).
Wenn man natürlich zwischen HTML-Ausgabe und DB nur ein bisschen Templategefummel oder ähnliches hat, braucht man nicht viel Design. Es gibt aber auch durchaus nicht-GUI-Anwendungen, die komplexer sind, als diese einfachen DB-Anwendungen.
Eine Verwaltungsanwendung, die im wesentlichen Daten abfragt und verändert, ist bezüglich dieses Aspektes eben einfach, weil praktisch keinerlei Berechnungen stattfinden, die organisiert werden müssten.
Sobald viele Infomationsflüsse in der Anwendung realisiert werden müssen, klappt das nicht mehr so einfach. Eine ereignisbasierte Simulationsanwendung  wäre dafür ein schönes Beispiel.

Grüße

Daniel

[hkl]

Um das vll noch mal abstrahiert darzustellen: Wie strukturiere ich GUI und den Programmkern, bzw. wie verknüpfe ich beide am besten?

Wenn Du eine normale Anwendung schreibst, also nicht mit Spezialsoftware hantierst, dann machst Du am besten folgendes:
1.) die DB designen
2.) den Datenzugriff (SQL) entweder als so genannte stored procedure im RDBMS ablegen oder modularisiert (d.h. absolut vom UI-Code getrennt) im Code (Ersteres ist vorzuziehen)
Dann hast Du das System geschrieben, d.h. alles, was Deine Anwendung können soll, kann Sie schon. Aber nur "per Hand" im Query-Tool Deines RDBMS. das reicht uns noch nicht, also:
3.) UI-Code schreiben, schön modularisiert und zwar "parallel" zum Datenzugriffscode. Also ich meine so "1:1", ach ich weiss jetzt auch nicht wie ichs schreiben soll.   ;)

Hallo Hamstar !

Glaube zu vertehen wie Du's meinst, aber kann man nicht die "Welten" mittels einer Singleton-Fassade voneinander trennen ?

DIE koennte man dann so prozedural odr OO-like skalieren wie man's grade braucht.

Sowas wie "Fenster", "Rahmen", oder "Document" und "View"  finde ich praedstiniert fuer einen OO-Ansatz;  Gamma et al. geben ja sogar einen WYSIWYG-Editor als Fallstudie.

Den Bruch zwischen OO und RDBMS kann man doch mittels DAO ( allgemein; nicht das was MS ausliefert ) oder halt einem threadsicheren Single Access Point ( Singleton::getInstance() ) kaschieren, oder ?

Nur von 1:1 Modell/Form ( wie bei MS - Recordset Forms ) ist, denke ich, Abstand zu nehmen.
Wenn, dann sollte man SPs OO-klammern, oder ?

Gruesse

Holger

Es gibt objektorientierte Ansätze fürs UI, aber ich lass davon die Finger weil sich m.E. eine "normale" Anwendung (viele Transaktionen aufs RDBMS) mit Objektorientiertheit beisst.

Aber "it depends", schreibst Du Grafikprogramme oder Editoren oder Tabellenkalkulationen, also Anwendungen die "UI-komplex" sind, dann kommst Du am Verständnis dessen was Franky so geschrieben hat, nicht vorbei. Viel Spass!   ;)

[Hamstar]

Glaube zu vertehen wie Du's meinst, aber kann man nicht die "Welten" mittels einer Singleton-Fassade voneinander trennen ?

Was ist eine Singleton-Fassade?

DIE koennte man dann so prozedural odr OO-like skalieren wie man's grade braucht.

Was ist OO-like skalieren?

Sowas wie "Fenster", "Rahmen", oder "Document" und "View"  finde ich praedstiniert fuer einen OO-Ansatz;

data grid oder single dataset edit, ja, warum nicht? Wenn Du Lust hast, kannst Du mir Deine Beispiele erklären.

Gamma et al. geben ja sogar einen WYSIWYG-Editor als Fallstudie.

Wer oder was ist "Gamma et al."?

Den Bruch zwischen OO und RDBMS kann man doch mittels DAO ( allgemein; nicht das was MS ausliefert ) oder halt einem threadsicheren Single Access Point ( Singleton::getInstance() ) kaschieren, oder ?

Bitte mal unter Nutzung möglichst vieler einfacher deutscher Wörter erläutern.

Nur von 1:1 Modell/Form ( wie bei MS - Recordset Forms ) ist, denke ich, Abstand zu nehmen.

Ebenfalls bitte erläutern, bei "MS - Recordsets Forms" verstehe ich nicht genau was gemeint ist.

Wenn, dann sollte man SPs OO-klammern, oder ?

Brr. Was soll da genau gemacht werden? (Spielst Du auf die Möglichkeit an unter MS SQL Server 2005 mit VS Studio bspw. T-SQL mit VB-Code zu mischen? Und dabei irgendwie OO vorzugehen?)

[hkl]

Hallo !

;-)

Glaube zu vertehen wie Du's meinst, aber kann man nicht die "Welten" mittels einer Singleton-Fassade voneinander trennen ?

Was ist eine Singleton-Fassade?

Ein Singleton, das eine Fassade realisiert.

DIE koennte man dann so prozedural odr OO-like skalieren wie man's grade braucht.

Was ist OO-like skalieren?

"prozedural odr OO-like skalieren"

1. Prozedurales und/oder OO-Interface schaffen, dabei
2. entscheiden ob sowas wie connect() ein Connection-Objekt liefert oder "nur" eine Ressource verwaltet.

Sowas wie "Fenster", "Rahmen", oder "Document" und "View"  finde ich praedstiniert fuer einen OO-Ansatz;

data grid oder single dataset edit, ja, warum nicht? Wenn Du Lust hast, kannst Du mir Deine Beispiele erklären.

Gamma et al. geben ja sogar einen WYSIWYG-Editor als Fallstudie.

Wer oder was ist "Gamma et al."?

Autoren von Design Patterns; aka "Gang of Four".

Den Bruch zwischen OO und RDBMS kann man doch mittels DAO ( allgemein; nicht das was MS ausliefert ) oder halt einem threadsicheren Single Access Point ( Singleton::getInstance() ) kaschieren, oder ?

Bitte mal unter Nutzung möglichst vieler einfacher deutscher Wörter erläutern.

DAO und "threadsicheren Single Access Point ( Singleton::getInstance() )"
erklaer ich 'mal

Wenn man ein, ggf. hinter einer Singleton-Fassade (s.o.) verstecktes Subsystem fuer den DB-zugriff schafft. erhaelt man durch die getInstance() (Klassen)Metode einen globalen Zugriffspunkt auf dieses Subsystem.

Dieser sollte threadsicher sein; deshalb muessen alle (Klassen-)Methoden die von dem Eexemplar bereitstellt werden auch threadsicher sein.

DAO

  
#include <string>  
  
// abstract  
class DAO  
{  
//[...]  
  public:  
    /* abstract*/ virtual int write_to_db() = 0;  
    /* abstract*/ virtual int read_from_db() = 0;  
//[...]  
};  
  
class Foo : public DAO  
{  
private:  
  unsigned integer m_id;  
  std::string label m_label;  
//[...]  
public:  
  /* virtual */ int write_to_db();  
  /* virtual */ int read_from_db();  
//[...]  
};  

zum Zugriff hierauf :

  
CREATE TABLE foo  
(  
  id UNSIGNED INTEGER NOT NULL AUTO_INCREMENT,  
  label VARCHAR(42),  
  PRIMARY KEY (id)  
);  

Nur von 1:1 Modell/Form ( wie bei MS - Recordset Forms ) ist, denke ich, Abstand zu nehmen.

Ebenfalls bitte erläutern, bei "MS - Recordsets Forms" verstehe ich nicht genau was gemeint ist.

MFC Class Wizard : Mapping von DB-Feldern auf Widgets.

Wenn, dann sollte man SPs OO-klammern, oder ?

Brr. Was soll da genau gemacht werden? (Spielst Du auf die Möglichkeit an unter MS SQL Server 2005 mit VS Studio bspw. T-SQL mit VB-Code zu mischen? Und dabei irgendwie OO vorzugehen?)

Man kapselt nicht (nur) einzelne Tabellen sondern SP's die man zum INSERT verwendet.

Bsp: Neuer Kunde / Neue Rechnung ( in 1 : n Relation )

Kunde anlegen => PK besorgen => Rechung anlegen => per Fk zu KD. zuordnen

Das ganze in einem (DAO-)Objekt.

Gruesse

Holger

P.S.:

VB-Code

"VB-Code" kenn ich nicht. Was ist das ?
VielLeicht "Visual Beginner's All Purpose Symbolic Instruction Code Code" ?
Also die "Allzweckanleitungssprachesprache fuer Menschen die sehen lernen" ?
:-)

P.P.S.:
Karl Lagerfeld, zu einer neuen BOSS-Kollektion befragt:
"Boss ? Boss ?? Hogo Boss ??? Kenn ich nicht - wer ist das ????"

[Hamstar]

Trotz all dieser Fachwörter meine ich so halwegs verstanden zu haben, was Du diskutieren möchtest. Anscheinend die Kapselung des Datenzugriffs. Während ich nicht davor zurückschrecke SPs direkt aus dem Code aufzurufen (bei der Pflege und Weiterentwicklung derselben also die Abwärtskompatibilität der SP-Aufrufe beachten muss) möchtest Du anregen eine zusätzliche Schicht einzuziehen, die den Datenzugriff (bspw. auf ein RDBMS) kapselt, d.h. es werden Objekte wie "Server" oder "DB" aufgebaut und dann deren Prozeduren wie bspw. NewContract() oder NewCustomer() aufgerufen.

Dann ist man flexibler, kann also bspw. das RDBMS abhängen und durch ein anderes ersetzen (mit einem anderen SQL-Dialekt und anderer Parametriesierung der SPs (wenn es überhaupt noch SPs sind)) und muss nur die einzelnen Datenzugriffs-Klassen anpassen.

Ist es das was Du meinst? Falls ja, kann ich meine Meinung dazu gerne abrufen und hier schriftlich niederlegen.

[hkl]

Hallo Hamstar!

Trotz all dieser Fachwörter meine ich so halwegs verstanden zu haben, was Du diskutieren möchtest. Anscheinend die Kapselung des Datenzugriffs. Während ich nicht davor zurückschrecke SPs direkt aus dem Code aufzurufen (bei der Pflege und Weiterentwicklung derselben also die Abwärtskompatibilität der SP-Aufrufe beachten muss) möchtest Du anregen eine zusätzliche Schicht einzuziehen, die den Datenzugriff (bspw. auf ein RDBMS) kapselt, d.h. es werden Objekte wie "Server" oder "DB" aufgebaut und dann deren Prozeduren wie bspw. NewContract() oder NewCustomer() aufgerufen.

Dann ist man flexibler, kann also bspw. das RDBMS abhängen und durch ein anderes ersetzen (mit einem anderen SQL-Dialekt und anderer Parametriesierung der SPs (wenn es überhaupt noch SPs sind)) und muss nur die einzelnen Datenzugriffs-Klassen anpassen.

Ist es das was Du meinst?

So in etwas. Wir hatten das schon mal ( Microsoft-) platformspezifisch andiskutiert.

Mir geht's darum nicht mit DB-Tabellen im GUI rumzufummeln. Diese Tabellen kann man kapseln und in ein Subsystem legen das man tunlichst hinter einer Fassade versteckt.

Im mittleren Layer und im GUI tauchen dann nur noch Objkete auf die auch wirklich etwas "leisten" und nicht nur OOP 1:1 auf SQL abbilden.

Man koennte die DAO-Klassen INNERHALB des DB-Subsystems dann uebrigens recht typarm halten, so ala

std::map<_variant_t>

und falsche Parameterisierung im Subsystem durch Exceptions / Asserts abfangen - so koennte man erreichen dass die App bei Aenderungen im DB-Design nur geringe Code-Aenderungen erfahren muss.

Das ist etwas schwierig ohne eine (Layer-)Graphik zu beschreiben.

Gruesse

Holger

[Hamstar]

Mir geht's darum nicht mit DB-Tabellen im GUI rumzufummeln. Diese Tabellen kann man kapseln und in ein Subsystem legen das man tunlichst hinter einer Fassade versteckt.

Grundsätzlich ist das sicherlich eine Idee, aber:
1.) der Aufwand ist beträchtlich
2.) man hält die Objekte in der Datenzugriffsschicht (SQL) und in der Geschäftslogikschicht so zu sagen doppelt
3.) der Nutzen ist zweifelhaft (das Abhängen bspw. des RDBMSs und Anhängen eines anderen) dürfte wohl so oder so schwierig sein
4.) man hantiert natürlich nicht mit Tabellen sondern mit Prozeduren wie SET_CONTRACT, LET_CONTRACT, GET_CONTRACT, LST_CONTRACT oder BIZ_GROUPED_CONTRACTS, also ganz CRUDLig.

und falsche Parameterisierung im Subsystem durch Exceptions / Asserts abfangen - so koennte man erreichen dass die App bei Aenderungen im DB-Design nur geringe Code-Aenderungen erfahren muss.

Ich erreiche das durch Abwärtskompatibilität der SPs.

Das ist etwas schwierig ohne eine (Layer-)Graphik zu beschreiben.

Ich versuch mal ein Schichtenmodell:
|GUI|BizObjects|DataAccess|Data|

LOL

[hkl]

Hallo !

Das ist etwas schwierig ohne eine (Layer-)Graphik zu beschreiben.

Ich versuch mal ein Schichtenmodell:
|GUI|BizObjects|DataAccess|Data|

Ich auch:
*-------*

Oben
Mitte
-----
Unten
*-------*
;-)

Gruesse

Holger

[Frank (no reg)]

Servus Hamstar!!!

Brr. Was soll da genau gemacht werden? (Spielst Du auf die Möglichkeit an unter MS SQL Server 2005 mit VS Studio bspw. T-SQL mit VB-Code zu mischen? Und dabei irgendwie OO vorzugehen?)

Du weisst nichts oder treffender "wenig", möchtest du evt. einen 3Tages Weiterbildungskurs über SQL 2005 & .Net bei mir buchen? Ich könnte dir auch Patterns näher bringen ;)

Ciao, Frank

[Hamstar]

Du weisst nichts oder treffender "wenig", möchtest du evt. einen 3Tages Weiterbildungskurs über SQL 2005 & .Net bei mir buchen? Ich könnte dir auch Patterns näher bringen ;)

Deine Rolle in diesem Beitragsstrang ist eine sehr zweifelhafte. Statt wie für eine IT-Fachkraft eigentlich üblich mit einfachen Worten und Schilderungen den Sachverhalt zu erörtern, kommen Bemerkungen zu Wald und Wiese (in Deinem Jargon forest und grassland vermutl.).

[Frank (no reg)]

Salut,

Deine Rolle in diesem Beitragsstrang ist eine sehr zweifelhafte. Statt wie für eine IT-Fachkraft eigentlich üblich mit einfachen Worten und Schilderungen den Sachverhalt zu erörtern, kommen Bemerkungen zu Wald und Wiese (in Deinem Jargon forest und grassland vermutl.).

Ach ... ?!?
Habe irgendwie das Gefühl, dass du meine Rolle etwas verwechselst?!
Wald und Wiese? Keine Ahnung womit du ein (Verständnis)Problem hast, aber du darfst es gern nochmal versuchen vorzutragen.

Meine Anspielung auf dein Unwissen in hinsicht mit SQL 2005/VB kommt nicht von ungefähr. Wenn das schon in deinem Dunstbereich liegt (berufst dich sonst auch immer auf "Daten*") dann solltest zumindest wissen, dass du den Code nicht mischst sondern mit T-SQL in T-SQL Syntax auf in IL-Code (.Net Zwischensprache) geschriebene Funktionen wie native Funktionen des SQL Servers zugreifst. Was meinst du, wie eine Systemfunktionen LEN oder SUBSTR implementiert sind? Magie? C?

Ciao, Frank

[Hamstar]

Wald und Wiese? Keine Ahnung womit du ein (Verständnis)Problem hast, aber du darfst es gern nochmal versuchen vorzutragen.

Es muss möglich sein mir bestimmte Sachverhalte zu erklären ohne mich mit buzz words und Marketinggesülze aus der Java bzw. MS-Welt zu belästigen. Insbesonders hkl ist für mich da ein Phänomen. Aber auch Deine Nachrichten sind unzureichend.

Meine Anspielung auf dein Unwissen in hinsicht mit SQL 2005/VB kommt nicht von ungefähr. Wenn das schon in deinem Dunstbereich liegt (berufst dich sonst auch immer auf "Daten*") dann solltest zumindest wissen, dass du den Code nicht mischst sondern mit T-SQL in T-SQL Syntax auf in IL-Code (.Net Zwischensprache) geschriebene Funktionen wie native Funktionen des SQL Servers zugreifst. Was meinst du, wie eine Systemfunktionen LEN oder SUBSTR implementiert sind? Magie? C?

Das ist mir schon klar. Danke dennoch für die (diesmal weniger arrogant vorgetragene) Lernnachricht.