Brauche Ideen für flexiblen/modularen Programmteil

[Jumpy]

Hallo zusammen,

ich hab mal wieder eine neue Aufgabe bekommen bei der es ein flexibles Element geben soll und ich hab keine Ahnung, wie man sowas umsetzt:

Im Programm soll es 3 Arbeitschritte geben:
1. Daten aus verschiedenen Datenquellen holen und in Tabelle schreiben
2. Daten ggf. einheitlich formatieren
3. Daten in einem bestimmten Format an ein Ziel übertragen.

Punkt 3 kann ich.
Punkt 2 kann ich auch, wobei es da einen flexiblen Teil geben könnte, da es zwar ein einheitliches Zielformat für die Daten gibt, aber untersch. Ausgangsformate, und es ja ggf. unterschiedliche Funktionen oder Regeln geben muss, wie aus Eingangsformat XYZ das Zielformat erreicht werden kann.

Punkt 1 ist nun mein Hauptproblem:
Daten sollen aus verschiedenen Datenquellen (DB, CSV-Import, LDAP) stammen können. Es muss also verschiedene Klassen oder gar Module geben für die Datenquellenart (vllt. mit einer abstarkten Klasse "Datensammler" als Vorfahre). Irgendwie muss das Programm wissen, welche Klassen/Datenquellen es bearbeiten soll (Z.B. holt es 2x Daten aus Oracle Tabellen in Datenbank A und eine Tabelle aus DB B, aus 2 CSV-Dateien, eine lokal, eine muss vorher per FTP geholt werden,...). Wie steuert man sowas von außerhalb des Programmcodes?
Was ist nun, wenn eine neue Art von Datenquelle hinzukommt? Wie krieg ich die eingebunden? Neue Klasse erstellen, alles neu kompilieren?

Oder sollte es für das Datensammeln jeweils eigene Programme geben, die mit Paramtern aufgerufen werden und die von dem Hauptprogramm aufgerufen werden.

Ich hab echte Schwierigkeiten mir Vorzustellen, wie sowas aufgebaut sein könnte und ich kann es auch nur schlecht formulieren, weswegen ich hoffe, das rübergekommen ist, was mein Problem ist und irgendwer von euch mich verstanden hat.

Umfeld ist zunächst Delphi6.

[jobo]

Tabellen kannst Du unter Oracke mit Hilfe von DB Links direkt zugreifen. Sofern die Datenbanken sich technisch sehen können.

CSV kannst Du per Oracle Loader in dutzenden Varianten importieren. Dazu muss die CSV allerdings auf dem Server liegen.

LDAP kann ich nichts zu sagen.

Die ersten beiden Fälle kannst Du vermutlich am besten via Oracle Stored Proc implementieren, die Du in Deinem Programm nur anstösst.

[Gustav.R]

"Oder sollte es für das Datensammeln jeweils eigene Programme geben, die mit Paramtern aufgerufen werden und die von dem Hauptprogramm aufgerufen werden."

OMG, bitte niemals!

Bloß nicht modular werden, denn millionen von Dir zu pflegende Zeilen sichern Deinen Job...

Sorry für OT

[Jumpy]

Ich hab mir schon gedacht, dass nicht ganz klar ist wie ich das meinte.
Die individuelle technische Seite des "Daten holens" krieg ich schon hin. So gibt es z.B. schon ein Klasse, die den Zugriff auf den OracleLoader kapselt, die ich da einsetzen würde. Es geht mir eher um das Zusammenspiel. Wie krieg ich die verschiedenen Wege des Datenholens unter einen Hut und vor allem von außen sei es über eine Steuertabelle, eine INI oder sonstwie steuerbar. Zur Design-Time weiß ich nicht, aus welchen Datenquellen-Arten und welchen Datenquellen in diesen Arten, das Programm am z.B. 14.07.2012 seine Daten holt.

[jobo]

Deine Beschreibung klang eigentlich so, als ob die einzelnen Quellen interaktiv durch einen Benutzer geladen werden.
Soll das timer gesteuert sein? Oder sogar vollautomatisch- Programm merkt, wenn Daten sich ändern.... und lädt sie?

[DeddyH]

Ist das nicht der klassische Anwendungsfall für ein Interface?

[Jumpy]

Zitat von jobo:

Deine Beschreibung klang eigentlich so, als ob die einzelnen Quellen interaktiv durch einen Benutzer geladen werden.
Soll das timer gesteuert sein? Oder sogar vollautomatisch- Programm merkt, wenn Daten sich ändern.... und lädt sie?

Ahhhhhhrg. Merke gerade, dass ich das wichtigste vergessen habe. Die Anwendung soll einmal täglich automatisch laufen, z.B. als geplante Task oder sowas, oder alternativ nach Bedarf von einem Mitarbeiter manuell angestartet werden. Sie "macht dann ihr Ding" und beendet sich wieder.

Nutzer sollen vorher über den Tag verteilt über ein separtes Konfigprogramm festlegen können, woher die Daten diesmal geholt werden sollen, bzw. später sollen auch andere Programme (um deren Datenbasis es hier u.a. geht) in der Konfiguration anmelden können, dass sich bei Ihnen was getan hat und bei Ihnen daher beim nächsten mal Daten abgeholt werden sollen.


@DeddyH Ich hab noch nichts mit Interfaces gemacht, aber das ist warscheinlich einses der Stichworte die ich mir angucken muss. Wie ist dass denn dann wenn ich eine neue Klasse (für eine neue Datenquelle) implementieren will? Die bekommt dann auch das Interface und fertig? Wie melde ich die beim Programm an? Muss das Programm neu kompiliert werden? Geht das über dll's?

Ich werd mich da glaub ich erst in die entsprechenden Grundlagen einlesen müssen, deswegen sind so Stichworte wie Interface ein guter Anhaltspunkt. Zur Zeit seh ich mir gerade was über Fabriken (zur Erzeugung von Klassen/Objekten) an, weil ein Kollege meinte, dass da vllt. auch ein Ansatz zu finden wäre.

[jobo]

Das Programm benötigt also eigentlich keine GUI, sondern kann als Schedule laufen bzw. manuell angeworfen werden.

Wenn Du Interfaces für verschiedene Datenquellen baust, solltest Du eine "horizontale und vertikale" in Betracht ziehen.
Das wäre erstmal sowas wie ORADB, LDAP, FTP, CSV
Eine Datenquelle, die meinetwegen Klasse FTP ist (aus Anwendersicht), wird nach dem Down/Upload dann zu CSV weiterreichen.
Auf der Zielseite bietet sich eine oder mehrere Schnittstellentabellen an. Sie nimmt die Daten auf, kann sie prüfen, ablehnen, final importieren bzw. verteilen.

[Jumpy]

Zitat von jobo:

Wenn Du Interfaces für verschiedene Datenquellen baust, solltest Du eine "horizontale und vertikale" in Betracht ziehen.

Kannst du das nochmal näher erläutern wie du das mit horizontal und vertikal meinst?

[jobo]

Äh, so wie ich es anschließend beschrieben habe.

Horizontal und vertikal sind sicher kein Fachbegriff dafür.
Ich wollte eigentlich nur sagen, dass Du Deine Import Klassen verschachteln solltest, wenn nötig:

Code:

  DB
  CSV
  FTP
     >CSV
  LDAP
  ..