Dreischichtige Anwendungsgestaltung

[borncrush]

Hallo,

ich habe mal eine grundsätzliche Frage zur Gestaltung einer mehrschichtigen Anwendung im Praxisfall.

Ich möchte also ein Programm entwickeln, indem die GUI-/Datenverarbeitungs-/DB-Logik getrennt von einander sind.

Meine Idee war (ganz grob und aufs Relevante gekürzt):

1. Unit (DB-Logik):
Diese Unit kommuniziert direkt mit dem DB-Server, schickt die SQL-Statements etc ab. Stellt also Methoden und Funktion zur Verfügung für die Kommunikation mit dem DB-Server.

2. Unit (Datenverarbeitung):
Diese Unit schickt das SQL-Statement an die 1. Unit und erhält ein Ergebnis (ResultSet). Nun stelle ich mir das so vor, dass mein Programm für die einzelne Datenbank-Inhalte Objekte/Klassen/Records zur Verfügung stellt. Beispiel (!!) :

Code:

SQL-query: SELECT * FROM Debitoren WHERE id=123;

Nun packt diese Unit das Ergebnis in ein Record:

Delphi-Quellcode:

TKunde=record
  sKundenNr:String[50];
  sName:String[50];
  .
  .
  .
end;

Delphi-Quellcode:

var BspKunde:TKunde

BspKunde.sKundenNr=ResultFromSQL.GetStringByName('Kundennummer')

3. Unit (GUI):
Diese Unit holt aus der 2. Unit das Objekt/Record etc. und füllt die GUI damit. Gleichzeit wird beim Abspeichern der Daten wieder ein Object/Record (vom Typ TKunde) gefüllt und an die 2. Unit übergeben (diese wiederum wandelt das Ganze in einen SQL-Statement [insert] um und schickt das an die 3. Unit, welches dann die DB-Kommunikaton auslöst.)



Ich hoffe man versteht, was ich meine.

Ist dieser Weg sauber und in Ordnung oder wie würdet Ihr es machen?

Viele Grüße

[Bummi]

Wenn Deine Units in ein und dem selben Programm sind sehe ich keinen Vorteil gegenüber direktem Zugriff (Dataset/Datasource/Datacontrol) sondern nur unnötigen Overhead.
Anders sieht das ganze aus wenn Du von einer Multitier Umgebung ausgehst. Mit einem Dienst der (verschieden) Datenquellen anzapft, die Datenlogik komplett abbildet und nach außen Schnittstellen für verschiedest Clients anbietet. Aber selbst da bin ich der Meinung dass Delphi hierfür nicht optimal geeignet ist, bzw. daß Du auf vieles verzichten musst was Delphi ansonsten von Haus aus mitbringt, ganz abgesehen von dem erheblichen Mehraufwand.

[WM_CLOSE]

Am besten ist es, wenn du die DataSource komponenten nutzt. Das ist schon eine relativ gute Trennung. Weiter würde ich nicht gehen.
PS: Ich habe diese Woche einen Thread zur Unitlänge angefangen. Die Unit mit 18k Zeilen hat in etwa den selben Grund.

[r2c2]

Zu TDataSource &Co. kann ich nicht viel sagen, weil ich die noch nicht benutzt hab. Aber ich kann diesen Artikel von Martin Fowler zu genau dem Thema empfehlen. Die Beispiele sind zwar in Ruby, aber das sollte sich dennoch leicht übertragen lassen...

mfg

Christian

[borncrush]

Danke für die Antworten! Der Artikel ist wirklich klasse. Da ich mich persönlich auch nicht mit den DB-Controls auskenne, werde ich nochmal gut über den Artikel nachdenken. Ist ein wirklich guter Ansatz. Gefällt mir.

Gruß

[Lemmy]

Hallo,

bitte schau dir diese beiden OPF/ORM an:
http://www.instantobjects.org/
http://tiopf.sourceforge.net/

die bieten alles das was Du dir selbst aus den Fingern saugen willst schon fertig an....

Zumindest InstantObjects sind relativ einfach. Spiel mit denen etwas herum. Je nach deinen Anforderungen könnte eines der beiden genügen. Wenn Du dann weiter Interesse an einer mehrschichtigen Anwendung hast, und das alles selber machen willst, dann schau dir das hier noch an:

http://www.ambysoft.com/downloads/persistenceLayer.pdf
http://www.tabdee.ltd.uk/papers/BuildingAnOpf.html

Und je nach Umfang deiner Anwendung loht der Aufwand schon - kann ich aus eigener Erfahrung sagen...

Grüße