Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi Strukturierung eines Datenbankprogramms (https://www.delphipraxis.net/111363-strukturierung-eines-datenbankprogramms.html)

sunny-andy 2. Apr 2008 10:16


Strukturierung eines Datenbankprogramms
 
Hallo!

Ich stehe vor dem Problem, ein bestehendes Projekt mal richtig zu strukturieren.
Ich habe z.B. eine abstrakte Datenzugriffsschicht, welche ein Auswechseln der DB erlaubt, dann die konkrete Datenbankzugriffsschicht.
Zusätzlich gibt es natürlich das Datenmodell mit allen Objekten, außerdem noch die View mit Forms und Frames.

Ich weiß nicht so recht, wie ich die Verzeichnisstuktur in Delphi strukturieren soll. Ist es vorteilhaft, alle Exceptions in einen bestimmten Ordner zu tun oder jede Exception dorthin zu kopieren, wo sie gebraucht wird?

Und ist es gebräuchlich, die Ordnerstruktur inhaltlich zu unterteilen? Also z.B. Kunden, Vorgänge, Firmen in getrennte Ordner zu verwalten oder doch lieber nach Model, View usw... ?

Ich hoffe, ihr könnt mir ein paar Tipps geben :zwinker:
Gruß,
Andy

shmia 2. Apr 2008 10:38

Re: Strukturierung eines Datenbankprogramms
 
Du solltest auf jeden Fall, die Units, die nicht auf eine bestimmte Anwendung bezogen sind in einem eigenen Verzeichnis (z.B. C:\Delphi\Lib) halten.
Diese Unit dürfen natürlich keine projektbezogenen Units einbinden!
Mit der Zeit baust du dir so deine eigene Library auf.

Alle projektbezogenen Units zu einem Projekt sollten in einem eigenen Verzeichnis (z.B. C:\Delphi\Firma\ProjektA) liegen.
Ich denke nicht, dass es Sinn macht, diese Units noch weiter in Unterverzeichnissen zu verstreuen, ausser vielleicht bei ganz grossen Projekten.

Ich speichere den ganzen Sourcecode nur auf Platte C:, weil bei Benützung einer Versionverwaltung (z.B. JediVCS) es Probleme gibt, wenn ein Rechner keine Platte D: hat.

Hansa 2. Apr 2008 10:46

Re: Strukturierung eines Datenbankprogramms
 
Ehrlich gesagt, die Frage ist mir zu theoretisch. Der Endanwender sieht auch keine "abstrakte Zugriffsschicht", sondern nur das, was ihm auf dem Bildschirm angezeigt wird. Üblicherweise trennt man das Programm von den Daten. Letztere verteilt man aber auch nicht beliebig über die Festplatte. Sieht fast eher nach dateibasiert aus, als dass es sich um eine Datenbank handelt. Angegeben wurde in der Richtung überhaupt nichts.

Dann das hier :
Zitat:

Zitat von sunny-andy
...oder jede Exception dorthin zu kopieren, wo sie gebraucht wird?

Da sage ich nur : "Never eat Exceptions". :mrgreen: Warum soll man die rumkopieren ? Es geht darum, so etwas möglichst schon im Vorfeld auszuschließen und nur unvermeidliche Exceptions abzuhandeln. Du musst viel genauer erklären, um was es geht. Was bspw. ist ein "View mit Forms und Frames" ? :shock:

sunny-andy 2. Apr 2008 11:01

Re: Strukturierung eines Datenbankprogramms
 
Hallo,

ich glaube, ich habe mich nicht deutlich genug ausgedrückt.


Zitat:

Ich denke nicht, dass es Sinn macht, diese Units noch weiter in Unterverzeichnissen zu verstreuen, ausser vielleicht bei ganz grossen Projekten.
Also das Projekt hat mittlerweile einen Umfang von genau 188 Units. Ich würde die schon gern vernünftig stukturieren.


Zitat:

Der Endanwender sieht auch keine "abstrakte Zugriffsschicht", sondern nur das, was ihm auf dem Bildschirm angezeigt wird.
Vielleicht habe ich das nicht deutlich zum Ausdruck gebracht, ich meine die Strukturierung der Quelltextdateien. Nicht die Ordnerstruktur, die dem Kunden geliefert wird.

Zitat:

..oder jede Exception dorthin zu kopieren, wo sie gebraucht wird?
Damit meine ich folgendes: Wo in der Projektstruktur gehören meine selbst erstellten Exception-Units hin?

Zitat:

Was bspw. ist ein "View mit Forms und Frames" ?
Die View aus dem MVC-Konzept. Struktiert man die Units des Projektes nach Model, View, Controller oder nach inhaltlichen Gesichtspunkten?

Hansa 2. Apr 2008 11:21

Re: Strukturierung eines Datenbankprogramms
 
Also gut, habe mal bei mir genauer geguckt. Jedes Projekt hat zuerst mal seinen eigenen Ordner. Bei 2 Fällen sind das 171, bzw. 402 PAS-Dateien (teilweise recht große). ALLERDINGS ! Hinzu kommt ein gemeinsamer Ordner mit 205 PAS. Ich sehe da keinen Sinn, das noch weiter zu zersplitten. Die Datenbank liegt unterhalb der jeweiligen EXE im Ordner DB. Die Speicherorte sind allerdings per INI einstellbar. Tja, das wars. :P

alzaimar 2. Apr 2008 12:26

Re: Strukturierung eines Datenbankprogramms
 
Ich definiere die Exceptions in der Unit, in der auch die Klasse definiert ist, die diese Exception schmeisst.

Zur Ordnerstruktur:
Ich verwende pro Projekt einen eigenen Ordner (und natürlich irgendwo meine Libary(
Dort steht mindestens:
ein Unterordner 'App', der enthält die Kompilate
ein Unterordner 'Shared', der enhält die gemeinsamen units
ein Unterordner 'Docs', der enhält Dokumentationen, Vorgaben etc.

Dann besteht so ein Projekt ja aus Subsystemen, die all irgendwelche Teilaufgaben bewerkstelligen und unabhängig voneinander arbeiten. Die projektbezogenen, subsystemübergreifenden Units packe ich in einen eigenen 'Shared' Ordner.

Somit sieht mein Projektverzeichnis so aus:
  • Projects/Company/ProjectA/App
  • Projects/Company/ProjectA/Docs
  • Projects/Company/ProjectA/Shared
  • Projects/Company/ProjectA/Subsystem_1
  • ...
  • Projects/Company/ProjectA/Subsystem_n
Jedes Subsystem bekommt einen Prefix aus 2 Buchstaben (Kundenmodul z.B. 'Kd'). Alle Units dieses Subsystems heißen 'KdXXXXXX.PAS'.

Wenn man, wie Hansa, keinen Bock hat, die Subsysteme in einzelne Verzeichnisse zu packen, dann eben nicht. Das ist letztendlich Geschmackssache. Und wenn jedes Subsystem nur aus 2 Units besteht, spare ich mir das auch noch.

Meine Projekte bestehen jedoch i.A. aus 5-20 einzelnen Tools, sodaß hier die Subsysteme durch einzelne Tool-Unterverzeichnisse ersetzt werden.

Hansa 2. Apr 2008 19:44

Re: Strukturierung eines Datenbankprogramms
 
Zitat:

Zitat von alzaimar
Wenn man, wie Hansa, keinen Bock hat, die Subsysteme in einzelne Verzeichnisse zu packen, dann eben nicht...

Ich wäre nicht zu faul dazu, aber nur, wenn es denn tatsächlich Sinn macht. :mrgreen: Aber das wird jetzt sowieso zu speziell. Hätte ich diverse Projekte, die aber auch gar nichts miteinander zu tun haben, dann sähe es wohl anders aus. Es gibt für individuelle Anpassungen ja auch noch anderes als schlichte Ordner. Z.B. IFDEF. Dann hat man eine Codebasis und kann sie mit entsprechenden Programmen auch anpassen. Dass jeder geänderte Buchstabe auch regelmäßig gesichert werden muss, das versteht sich IMHO von alleine. Gilt übrigens auch für Kommentare !

Chemiker 3. Apr 2008 19:09

Re: Strukturierung eines Datenbankprogramms
 
Hallo,

ich finde das Thema ganz interessant!

@Hansa: Wie behältst man den Überblick bei 402 pas – Dateien? Ich habe jetzt nicht die pas – Dateien gezählt, aber es sind mit Sicherheit weniger. Ich versuche schon seit jahrzehnten da eine Vernünftige Struktur reinzubekommen, aber nach den letzten Festplatten – Crash hatte ich 4Tage damit verbracht das aktuelle Projekt einigermaßen wieder herzustellen. Also ist meine Struktur immer noch nicht optimal.
@alzaimar: So ähnlich habe ich auch meine Ordnerstruktur. Nur wie geht man da vor, wenn man an mehre Rechner arbeitet (z.B.: Win 2000, XP) und mit mehreren Delphi – Versionen.

Bis bald Chemiker

Hansa 3. Apr 2008 22:17

Re: Strukturierung eines Datenbankprogramms
 
Zitat:

Zitat von Chemiker
...ich finde das Thema ganz interessant!

@Hansa: Wie behältst man den Überblick bei 402 pas – Dateien? ...

Hat mich selber gewundert. Aber nur wegen Objektablage. Ich leite die Forms vom Vorgänger ab. Das ergibt schon eine gewisse Anzahl an Forms. Die können schon überdiemsioniert sein, sofern alles mehrfach deklariert wird. Mache ich aber nicht ! Die bauen aufeinander auf.


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:03 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