C# ausführen von Skripten

[bado]

Hi und guten Morgen!

Ich bastele derzeit ein Programm das sehr generisch sein soll. Es werden Daten von irgendeiner Datenbank eingelesen, dann je nach Konfiguration verarbeitet und in irgendeine Datei ausgegeben. (Geht um eine konfigurierbare Schnittstelle)

Der Teil der mir logisch noch zu schaffen macht ist die Verarbeitung. Es soll möglich sein, die eingelesenen Daten auf unterschiedlichste Weise zu bearbeiten, also anders gesagt die Methoden die zur Bearbeitung ausgeführt werden sollen, sind mir nicht bekannt. Es kann nun also sein das Ergebnisfelder der eingelesenen Daten aufsummiert werden sollen, oder validiert oder sonst was.

Überlegt hätte ich mir jetzt diese Funktionen in irgendeiner Skriptsprache in eigenen Dateien abzulegen. Und zusätzlich ein XML File mit dessen Hilfe definiert wird, welche Scriptdatei für welche Funktion steht. Der Vorteil wäre das die Kunden sich diese Funktionen selber zusammenbasteln können, ohne das mein Hauptprogramm neu kompiliert werden muss. (Quasi Dependency Injection)
Ich weiß es gäbe zb. MEF um das mit anderen C# (oder .net) Klassen zu realisieren, ich will aber eigentlich nicht, dass die Kunden dann eigenen Klassen Schreiben müssen, sondern eben einfach einen Editor aufreißen und 10 - 20 Zeilen (als Beispiel) VBS Code reinklopfen und fertig.

Das Hauptprogramm müsste dann irgendwie dieses Script ausführen und einen Rückgabewert erhalten.
Und genau da liegt derzeit mein Problem. IRGENDWIE

Ist das so überhaupt sinnvoll?
Ich muss dazusagen diese Funktionen sind eher primitiv, es geht wie gesagt um Aufsummieren von Daten und Entscheidungsfragen (wenn das dann das usw.)
Hätte mir schon überlegt das auch irgendwie in einem XML abzubilden, aber ich denke das ich nie so flexibel werde wie mit einer wirklichen Scriptsprache mit dessen Hilfe ich quasi alles mit den Daten anstellen könnte.



Danke im Voraus

BaDo

[defo]

Wenn es so simpel sein soll, reicht es dann nicht eine Feldliste mit Aggregat und ein paar Expression Möglichkeiten anzubieten und das in SQL abzufragen?
Man müsste also anhand einer Feldliste und einer Group by Liste (und ggf Where Clause für Filter) ein Statement zusammenbauen und auf die Datenbank loslassen. Klingt relativ übersichtlich und eigentlich schon sehr mächtig. Joins stehen ja wohl nicht an, wenn ich das richtig verstanden hab.

[fanderlf]

Falls die Skripte nicht recht komplex werden würde ich einfach bei SQL bleiben. Du schmeisst ein SQL Statement rein und bekommst eine Datei wieder heraus. Das sollte sehr einfach machbar sein. Ob die andere Firma jetzt SQL oder eine andere Sprache lernen muss sollte eigentlich egal sein. Für etwas komplexere Szenarien könnte man sich z.B. mal LUA anschauen: https://github.com/chkn/AluminumLua. Das ist soweit ich weiss auch bei Spielen sehr beliebt als Skriptsprache. Oder man wertet C# Code zur Laufzeit aus ähnlich dem hier: http://flee.codeplex.com/.

Wenn Du Dich für ein Verfahren/Framework entscheidest würde ich nochmal prüfen wie aktuell die sind. Ich hab nur eben mal auf Google was zusammen gesucht. Es gibt bestimmt noch andere Frameworks um das ein oder andere zu suchen. Für die Qualität und Aktualität der Frameworks würde ich jetzt keine Garantie übernehmen

[bado]

Hi und danke für die schnelle Antwort

Es sind schon mehrere Tabellen also auch JOIN´s. Es geht um eine FIBU Schnittstelle, da kann wie gesagt alles mögliche passieren. Irgendwelche Sätze aufgrund von irgendwelchen Spalteninformationen zu Aggregieren ist wichtig, aber eher noch das einfachste.
Sachen die auch auftreten können währen zb. wenn in Satz xy eine Gegenkontonummer von 1110 steht diese mit 1150 austauschen usw.
Oder eben Summenbeträge aufsummieren, aber nur wenn zb. (nur ein Beispiel) die Kontonummer 'Banane' ist

Man sieht diese Aufgaben sind alle eher trivial, aber ob das alles so einfach mit SQL abzubilden ist, damit es auch Generisch bleibt ist wohl fragwürdig :/

[bado]

Hmm ich glaube ich schau mir das mit den SQL Strings mal an, also wie komplex die im schlimmsten Fall werden würden, und ansonsten denke ich werde ich wohl C# einbinden und zur Laufzeit kompilieren. Das wird wohl am wenigsten Schwierigkeiten machen zum Implementieren, und ganz ehrlich ob der der das dann konfiguriert nun LUA oder VBS oder C# reinklopft sollte egal sein. (Eigentlich )

Danke nochmal für die Antworten!

[defo]

Hmm ich glaube ich schau mir das mit den SQL Strings mal an, also wie komplex die im schlimmsten Fall werden würden

Wenn Du tatsächlich SQL direkt verwenden möchtest, liegt es ja allein in der Hand des SQL Schreibers und der DB Möglichkeiten, was alles machbar ist. Da sehe ich in der Umsetzung keine Probleme.
Ich hatte allerdings bewusst vorgeschlagen, nicht direkt SQL zu verwenden, sondern Strukturen (Feldlisten, Group Listen, ..) vorzugeben. Gründe dafür wären zum einen die notwendigen Skills beim erstellen der Abfrage, aber auch und nicht unwichtig Sicherheitsaspekte.
Wenn man einfach SQL eingeben kann, stehen Fehlern, unerlaubtem Datenzugriff und Manipulation oder Schäden durch falsche Verwendung Tür und Tor auf.
Dafür wäre dann per DB Roles festzulegen, welche Daten (Tabellen,Views) überhaupt abfragbar sind, update, insert, delete wären zu unterbinden und es müsste sichergestellt sein, dass diese Einschränkungen nicht durch Anmeldung mit anderen Accounts umgangen werden kann.
Der reine SQL Zugriff dürfte außerdem performanter sein, als eine clientseitige Verarbeitung, birgt aber auch die Gefahr, dass durch fehlerhafte Abfragen die DB lahmgelegt wird. (Fehlende Joins, ..)

Zuletzt noch der Hinweis, dass Du mit einem solchen Werkzeug ggF. die Lizenzbedingungen der FIBU verletzt und darüber hinaus auch Haftung des Herstelles wegfällt.

[bado]

Ja tut mir leid hab mich unklar ausgedrückt
Ich will keine fixen SQL Strings hinterlegen, sondern XML Strukturen erzeugen (wahrscheinlich mit einem Schema) über das Felder ausgewählt werden können. Und auch die Einschränkungen (WHERE) sowie GroupBy und OrderBy alles eben was DML technisch dazu gehört
Aber natürlich so eingeschränkt, das dass obligate TRUNCATE ARTIKEL; nicht möglich ist.

Für die aktuelle FIBU sollten diese Lizenzbedienungen alle passen, nachdem ich den Export der Daten aber generisch machen will (und somit auch eine andere FIBU theoretisch befüllt werden könnte), muss ich mich darüber wohl noch informieren!
(Danke für den Hinweis)

lg