Mehrere Schichten Programmieren

Hallo, ich habe eine Frage. Ich möchte eine Datenbankanwendung schreiben. Mir wurde immer gesagt dass man das Professionell am besten über mehrere Schichten machen sollte. Ich habe das zum Teil versucht. Ich habe eine eigene Datei für die GUI und eine für die Datei für die Datenbankanbindung. Jetzt weiß ich aber nicht richtig wie ich denn die Datensätze nachdem ich ich ausgelesen haben an die GUI weitergeben. Ich habe mir gedacht das über einen Vektor zu machen. Hat das ganze überhaupt sinn. Leidet die performance nicht darunter.

dschensky

Mr12,

Mr12 schrieb:

Hat das ganze überhaupt sinn. Leidet die performance nicht darunter.

sinnvoll ist es in jedem Fall. Über das Fernziel kannst Du etwas von dem offiziellen MVC-Jünger Junix in Erfahrung bringen.
Was die Performance betrifft: Ja, das kostet Performance, aber leiden wird der End-User wegen den 0.2 Millisekunden Wartezeit und dem Mehraufwand an Hauptspeicher i. Allg. nicht.
Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß und damit auch der Chef des Entwicklers, wenn er erfährt, daß das Projekt 4 Monate später fertig wird u.s.w. ...

Hi, danke. gut zu wissen. Ich halte auch sehr viel davon für die zukunft zu programmieren. Außerdem kann ich wenn es drauf ankommt einfacher die gui austauschen. Jetzt habe ich aber ein Problem. wie soll ich die datensätze an die Gui weitergeben. Ich weiß nicht wie ich das machen sollen. Soll ich die datensätze in einen Vektor reinschreiben und diese an die GUI weitergeben und in der gui dann auswerten ( zum beispiel in ein ListView) ? Wenn wie macht man sowas.

dschensky

Mr12,

Mr12 schrieb:

...Ich weiß nicht wie ich das machen soll...

also erst einmal sagt uns die Logik, daß die Daten in jedem Fall irgendwie auf den lokalen Rechner geschaufelt werden müssen, um sie z.B. im GUI vernünftig darstellen zu können.
Grundsätzlich fallen mir da zwei Methoden ein:

Eine Schicht, die die Tabellen-Struktur relationaler Datenbanken auf dem Client abbildet
Als da wären z.B. die Klassen TDataSet und TField, die direkt mit sogenannten Daten-sensitiven Steuerelementen kommunizieren können. Bei Borland heißen die dann z.B. TDBEdit, TDB...

Vorteil: sehr schnelle Programmierung möglich
Nachteil: OOP kann praktisch nicht genutzt werden

Sog. "Fachklassen" oder "Biz-Objects" (oder eben einfach nur "Klassen") in Verbindung mit einer Datenbankschicht
Die Datenbankschicht reicht auf Anfragen Objekte (und keine Tabellen) zwecks Verarbeitung oder Darstellung im GUI heraus bzw. übernimmt diese, um sie z.B. zu Speichern. Diese Objekte sind keine abstrakten Datensatz-Kopien sondern Modelle der Realität.

Vor/Nachteile: siehe 1), nur anders herum

Darüber läßt sich natürlich noch eine Menge mehr sagen - deshalb:
Lesen, Lesen und nochmals Lesen (wenn ich mal einen berühmten Revolutionsführer frei zitieren darf)

Hi, wo soll ich den sowas nachlesen. Für den Builder gibt es kaum was zu lesen. Ich habe schon den developer's guide. Ich weiß einfach nicht wie ich aus einer schicht die datensätze an die guischicht weitergeben soll. Ich habe das zuerst mit einem Vektor versucht aber es will nicht oder ich kann es einfach nicht. Ich bräuchte wirklich mal eine Lösung. Wie machen das die großen im Builder. Schreiben die sowas direkt in die guiklasse oder machen die das in mehreren schichten. dann müssen die ja auch das ganze hin und her zwischen den schichten verschicken können.

akari

Hallo

Ich arbeitete gerade an genau der selben Sache : eine objektorientierte, wiederverwendbare Struktur zum Umsetzen einer Datenbank-Anwendung. Und ich kann dir sagen, das man das nicht in ein paar Sätzen erklären kann. Du wirst dir da wohl selber etwas ausdenken müßen.
Der Ansatz mit der Trennung von nicht-visuellem Datenbank-Zugriff und visualler Datenanzeige ist schon mal richtig. Um das ganze zu kombinieren, brauchst du eine Schnittstelle, die Werte in einem bestimmten "Format" übergibt. Also die visuellen Komponenten fordern über die Schnittstelle Daten von Verwaltung an, und schreiben gegebenfalls Daten zurück in die Verwaltung, während die Verwaltung sich mit der echten Datenbank aktualisiert.
Wenn du es richtig machst, müßen die visuallen Komponenten nicht den genauen Typ der Datenquelle kennen, wie auch die Verwaltung auch ohne visuelle Komponenten arbeiten kann. Dazu brauchst du Basisklassen, Templates und eine Menge Zeit.

bis bald
akari

KlausB

Hallo

@akari

eine Menge Zeit

Welcher Kunde gibt dir eine Menge Zeit.
Meist ist es doch so
- verschiedene Angebote
- der billigste bekommt den Auftrag (leider)

Deinem Auftraggeber ist es (gelinde gesprochen) schwi.... egal
ob dein Programm schoen OO ist oder nicht
wenn dieser OO-Programm das 2-3 fache kostet

Ich habe selbst sowas schoen sehr oft erlebt und kann nur sagen
wenn man nur fuer sich Programmietr ist OO echt gut oder
wenn der Kunde bereit ist mehr Geld wie bei anderen hinzulegen auch
aber sonst - der Preos macht es - und sonst nichts

Wenn man dagegen nur fuer sich Programmiert ist es richtig

MfG
Klaus

akari

Hallo

tja, das mit der benötigten Zeit ist wohl das Hauptproblem.
Zum Glück habe ich einen Chef, der mit meinem Vorgehen einverstanden ist und das gegenüber den Kunden auch durchsetzt.
Dabei hilft natürluch der Umstand, das wir mehrere Projekte derselben Art (komplexe Datenbank) haben (werden), und deshalb eine solche zwar einmalig aufwendige, aber dafür wiederverwendbare Arbeit sich lohnt. Für einen Auftrag ist es Overkill, da hast du recht.

bis bald
akari

dschensky

Mr12,

Mr12 schrieb:

...wie soll ich die datensätze an die Gui weitergeben. ...

z.B. so - (ungetestet :))

DbLayer db = new DbLayer("MyRealDatabase");    //DB-Schicht erzeugen
Kunde k = new Kunde();    //Fachklassen-Instanz anlegen
db.GetKunde(k, 42);    //Kunde-Objekt mit bestimmtem primary key aus DB holen
TKundeForm f = new TKundeForm(this, db, k);    //GUI für Kunden erzeugen
f.ShowModal();    //Ansichts-/Bearbeitungs-Modus für Kunden starten
...
TKundeForm::Save()
{    //wird bei Klick auf Save-Button aufgerufen
    db->SaveKunde(k);
}

KlausB schrieb:

der Preos macht es - und sonst nichts

Meiner Erfahrung nach, kommen noch zwei weitere Punkte hinzu:

Die Anwendung muß "cool" aussehen. Ich wollte es anfangs gar nicht glauben, aber das spielt für viele eine große Rolle. Wenn der erste Eindruck ist: "Oh mann, das Programm sieht total altbacken aus!" habe ich genauso verloren, wie bei "Ach Du Scheiße, wer soll den das bezahlen!?". Und ich meine nicht nur Klicki-Bunti-Programme, wo der Teenager jeden Tag einen neuen Skin ausprobieren will, sondern auch dröge Büro-Anwendungen.
Das Programm muß einfach zu bedienen sein. Das heißt nicht, das es schlicht aussehen soll (siehe 1), sondern daß es möglichst intuitiv zu verstehen sein muß und das der Nutzer vom GUI unterstützt wird - etwa bei der Eingabe von Daten.
Mein Chef hat bei einer Messe potentielle Käufer angelockt, weil in seinem Hauptfenster ein riesiger Button mit der (ebenfalls riesigen) Aufschrift "Kunden" zu sehen ist - bescheuert, aber die Realität.
Überall wird gespart. Und wenn ein Unternehmer statt einer hoch qualifizierten Arbeitskraft eine schlechter bezahlte einstellen kann, weil es die Software ermöglicht, wird er sich für diese Software entscheiden - eine moralische Zwickmühle für Software-Entwickler?

Beide Punkte, um mal wieder auf das Wesentliche zurückzukommen, lassen sich mit OOP imho einfacher realisieren. Insofern spart man letztlich vielleicht sogar Zeit. Das Problem ist bloß, wie man den Kunden davon überzeugt.

junix

dschensky schrieb:

[...] Über das Fernziel kannst Du etwas von dem offiziellen MVC-Jünger Junix in Erfahrung bringen.

Ob ich diesen Titel als positiv oder negativ bewerten sollte? *grübel* (o;

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß und damit auch der Chef des Entwicklers, wenn er erfährt, daß das Projekt 4 Monate später fertig wird u.s.w. ...

Den hier versteh ich nicht... sprechen wir vom selben MVC?

-junix

junix

Ahja und @Mr12: wenn du in Richtung MVC gehst, dann sollte das doch eigentlich klar sein? Ich erstelle man ein grobes Objektmodell auf die Schnelle auf Basis von MVC:

|   Datenbankserver   |
|                     |
+---------------------+
            ^
            |
+---------------------+
|  Database Connector |
+---------------------+
            ^
            |
+---------------------+    +-------------+ 
|    Dein Dokument    |<-->| Deine Views |
+---------------------+    +-------------+
            ^                      ^
            |                      |
+----------------------------------------+
| Deine Datenbankapplikation             |
+----------------------------------------+

Folgende Erklärung:
Dein Dokument besitzt einen "Databaseconnector" und lädt über diesen von der Datenbank alle für sich nötigen Daten runter.
Das view holt sich die Daten (vorzugsweise Call by reference) aus dem Dokument und bearbeitet sie so das es sie anzeigen kann.

dschensky

junix,

junix schrieb:

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß und damit auch der Chef des Entwicklers, wenn er erfährt, daß das Projekt 4 Monate später fertig wird u.s.w. ...

Den hier versteh ich nicht... sprechen wir vom selben MVC?

wenn ich mal zitieren darf:
"In einem Satz ausgedrückt, bedeutet Document/View die Trennung von Datenspeicher- und Anzeigeobjekten."

Alexander Kempf

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß und damit auch der Chef des Entwicklers, wenn er erfährt, daß das Projekt 4 Monate später fertig wird u.s.w. ...

Wo steckt denn Deiner Meinung nach jetzt der Spaghetti-Code - in einer MVC-Implementierung oder in der
Ich-lege-einfach-mal-los-Implementierung?

Wenn ein Programmierer, der von MVC noch nichts gehört hat, derartigen Code betrachtet, wird er sehr
wahrscheinlich nichts verstehen und wirklich länger für Änderungen brauchen. Und eine MVC-Architektur
zu implementieren scheint zunächst auch mehr Zeit zu benötigen (die Übung macht's). Der Vorteil ist,
dass ich mir bei MVC vorher Gedanken über das Programm machen muss. Ich habe schon sehr viel
Code gesehen, bei dem man die Programmiermethode "wildes Rumprobieren bis es klappt" erkennen kann.
Da wird dann an allen möglichen Stellen im Programm ein Refresh aufgerufen und alle Daten neu ein-
gelesen, weil's wegen des schlechten Designs offensichtlich Probleme mit der Aktualisierung gab. Das
passiert meines Erachtens immer dann, wenn man die Logik bröckchenweise über das ganze Programm ver-
teilt und jedes Formular Zugriff auf jedes andere im Projekt hat, alle Variablen sind dann natürlich
mindestens public - besser global. So was zu warten, macht wirklich keinen Spaß. Wenn hier eine tief-
greifende Änderung im Arbeitsablauf vorgenommen werden soll, ist das schon bei einem mittelgroßen
Programm die Hölle.

Ich glaube, dass sich der Aufwand für ein gutes Design lohnt. Und die häufig gebrauchte Ausrede
"Das Programm wird nie erweitert werden" kann ich auch nur schwer gelten lassen - wer das be-
hauptet, spricht sich selbst ja schon hellseherische Fähigkeiten zu.

Gruß,

Alexander

akari

Hallo

Ich glaube, dass sich der Aufwand für ein gutes Design lohnt. Und die häufig gebrauchte Ausrede
"Das Programm wird nie erweitert werden" kann ich auch nur schwer gelten lassen - wer das be-
hauptet, spricht sich selbst ja schon hellseherische Fähigkeiten zu.

Full Ack. Wer einmal etwas für Dritte geschrieben hat, weiß, das sich die Anforderungen bereits im Laufe der Entwicklung (und danach erst recht) ändern. Und
dann sollte man dafür gesorgt haben, das selbst umfangreiche Änderungen nur an einer Stelle durchgeführt werden müßen und keine anderen Abläufe negativ beeinflußen.

bis bald
akari

junix

dschensky schrieb:

junix,

junix schrieb:

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß und damit auch der Chef des Entwicklers, wenn er erfährt, daß das Projekt 4 Monate später fertig wird u.s.w. ...

Den hier versteh ich nicht... sprechen wir vom selben MVC?

wenn ich mal zitieren darf:
"In einem Satz ausgedrückt, bedeutet Document/View die Trennung von Datenspeicher- und Anzeigeobjekten."

Tut mir leid, ich zermartere mir das Hirn und komm nicht drauf was du meinst bzw. hinaus willst....

dschensky

Alexander Kempf schrieb:

Wo steckt denn Deiner Meinung nach jetzt der Spaghetti-Code - in einer MVC-Implementierung oder in der
Ich-lege-einfach-mal-los-Implementierung?

Junix schrieb:

Tut mir leid, ich zermartere mir das Hirn ...

Ups, ich glaube, jetzt verstehe ich die Reaktionen. Die Aussage

dschensky schrieb:

Wirklich leiden wird der Entwickler, der sich durch das Spaghetti-Geflecht von Datenbank- und GUI-Code wühlen muß...

bezog sich (natürlich) auf den Fall, wenn man keine Trennung von Datenhaltungs- und GUI-Code vornimmt.
Ferner ist das eine allgemeine Aussage gewesen, unabhängig davon, wie eng man sich an die MVC-Theorie hält bzw. ob man diese überhaupt benutzt.