Brauche Ideen für flexiblen/modularen Programmteil
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. |
AW: Brauche Ideen für flexiblen/modularen Programmteil
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. |
AW: Brauche Ideen für flexiblen/modularen Programmteil
"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 |
AW: Brauche Ideen für flexiblen/modularen Programmteil
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. |
AW: Brauche Ideen für flexiblen/modularen Programmteil
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? |
AW: Brauche Ideen für flexiblen/modularen Programmteil
Ist das nicht der klassische Anwendungsfall für ein Interface?
|
AW: Brauche Ideen für flexiblen/modularen Programmteil
Zitat:
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. |
AW: Brauche Ideen für flexiblen/modularen Programmteil
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. |
AW: Brauche Ideen für flexiblen/modularen Programmteil
Zitat:
|
AW: Brauche Ideen für flexiblen/modularen Programmteil
Ä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 .. |
AW: Brauche Ideen für flexiblen/modularen Programmteil
Delphi-Quellcode:
TDatenSammlerClass = class of TDatenSammler;
TDatenSammler = class public procedure LoadFromFile(const AFilename: String); virtual; abstract; procedure SaveToTable(const ATable: TTable); virtual; abstract; end; TCSVImporter = class(TDatenSammler) public procedure LoadFromFile(const AFilename: String); override; procedure SaveToTable(const ATable: TTable); override; end; // #1 für weitere Formate - dementsprechende Klasse implementieren (von TDatenSammler ableiten) (...) implementation type TDatenSammlerExtAssoc = record Ext: String; _Class: TDatenSammlerClass; end; const DatenSammlerExtAssoc: Array[0..{anzahl der Datenformate - 1}] of TDatenSammlerExtAssoc = ((Ext: '.csv'; _Class: TCSVImporter), {...}); // #2 Wichtig: hier ^ registrieren function GetDatenSammlerClassFromExt(const AExt: String): TDatenSammlerClass; var i: Integer; begin for i := 0 to High(DatenSammlerExtAssoc) do with DatenSammlerExtAssoc[i] do if Ext = AExt then begin Result := _Class; break; end; end; {...später im Programm} var ldr: TDatenSammler; begin ldr := GetDatenSammlerClassFromExt(ExtractFileExt(Filename)).Create; ldr.LoadFromFile(Filename); ldr.SaveToTable(MyTable); ldr.Free; end; |
AW: Brauche Ideen für flexiblen/modularen Programmteil
Was Du da bauen sollst, nennt sich ETL-Prozess. Googel mal danach, es gibt auch einige Freeware ETL Tools. benetl z.B. ist für mysql und postgres. Schau dir die mal an, vielleicht bekommst Du Denkanstöße.
Wie DeddyH schon erwähnt hat, ist das ein gutes Beispiel für den sinnvollen Einsatz eines Interfaces. |
AW: Brauche Ideen für flexiblen/modularen Programmteil
Jede der genannten Datenquellen kann quasi direkt in ein DataSet überführet werden.
Code:
Dieses wäre dann der Extract-Teil, der Rest sollte dann eigentlich Spaziergang sein :)
............ Orcacle DB -> ??? -> DataSet
............ Orcacle DB -> ADO -> DataSet .................. LDAP -> ADO -> DataSet ...... lokale CSV-Datei -> ADO -> DataSet FTP -> lokale CSV-Datei -> ADO -> DataSet |
AW: Brauche Ideen für flexiblen/modularen Programmteil
Zitat:
Wenn Du hier über Prozesse sprichst, die große Datenmengen bewegen und Oracle als Ziel fix ist, denk doch noch mal darüber nach, ob sich eine direkte Durchführung der Ladeprozesse in Oracle nicht lohnen würde. Dein Programm würde sie dann nur starten. Ohne Oracle zu hypen: sobald der Prozess nativ auf dem Zielsystem (welches auch immer), also mehr oder weniger mit Bordmitteln oder hauseigenen Tools durchgeführt wird, hast Du maximale Performance und vermutlich auch Robustheit. |
AW: Brauche Ideen für flexiblen/modularen Programmteil
@all:
Erstmal danke für die rege Beteiligung. Komme wg. WE erst jetzt zum Antorten. Und das auch nur kurz, weil ich eure Anregungen/Links erstmal nur überflogen habe und mir das alles nochmal gründlich durchlesen will. @jobo & Furtbichler: ETL als Stichwort für den Vorgang ist sehr passend und ähnlich. Nur was die Datenmenge usw. angeht, wird das bei mir glaub ich nur der "kleine Bruder" von ETL :) (z.Zt. vllt. 2000 Datensätze aus allen momentanen Quellen (4), recht einheitliche Struktur, nur im kleinen müssen Formatanpassungen vorgenommen werden) @Aphton: Ich hab noch nicht alle Details deines Beispiels verstanden, aber das sieht schon sehr interessant aus. So wie ich die Konstruktion verstanden habe, kann ich über einen String (der wer weiß voher kommen kann, z.B. Parameter) festlegen, welche Klasse ich jetzt brauche. Wenn ich ein Datensammlerklasse mehrmals brauchen will müsste ich dann in dem Teil "später im Programm" sowas einbauen, wie "if GetDatenSammlerClassFromExt('blub') is nil then GetDatenSammlerClassFromExt('blub').Create" Sprich wenn erstmalig gebraucht, neu erzeugen, sonst wiederverwenden? |
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz