2009-11-20 3 views
5

Ich überlege, eine Skriptsprache in eines meiner Softwareprojekte einzubetten und habe zwei Optionen identifiziert: das Kompilieren von C# zur Laufzeit über CodeDOM und das Einbetten einer DLR-basierten Skriptsprache. Beide Optionen geben mir vollen Zugriff auf das .NET Framework.Gründe für die Verwendung einer DLR-basierten Sprache anstelle von C# für Skriptaufgaben?

Die Operation, die ich scripting wäre eine benutzerdefinierte Transformation eines DataRow und eine Reihe von Metadaten in einer modifizierten DataRow. Ich erwarte, dass diese Transformationen zusammensetzbar und häufig aufgerufen werden. Natürlich erwarte ich, dass die Transformationen vom Endbenutzer bereitgestellt und modifiziert werden können.

Gibt es angesichts dieser Arbeitslast irgendwelche klaren Vorteile gegenüber der Verwendung eines Ansatzes gegenüber einem anderen?

Antwort

3

Für Benutzer ist es aus offensichtlichen Gründen normalerweise besser, Sprachen mit einer fehlerverzeihenden Syntax zu verwenden. Daher würde ich empfehlen, eine DLR-basierte Sprache zu verwenden. Wenn Sie Zeit und Ressourcen haben, ist eine spezialisierte DSL die beste Wahl, weil Sie eine kleine und leicht zu erlernende Syntax anbieten können und es einfacher ist, den Benutzer davon abzuhalten, Dinge zu tun, die er nicht tun sollte (wie den Zugriff auf das Dateisystem) , zum Beispiel ...)

Ich kann nicht aus Erfahrung sprechen, aber von dem, was ich gesehen habe, kann das DLR ziemlich schnell sein (IronPython ist besser als natives Python!). Der dynamische Versand erfordert jedoch immer einen geringen Aufwand. Auf der fesselnden Hand sind Cross-AppDomain-Aufrufe ziemlich teuer. Während die dynamischen Versandkosten innerhalb des Skripts überall bezahlt werden, werden die cross-AppDomain-Kosten nur einmal pro Skriptaufruf bezahlt. Welche davon besser ist, hängt davon ab, wie viel Ihre Skripts tun werden.

Einbetten eines DLR Scripting Host ist not difficult at all. Was schwierig ist, ist das eigene DSL zu rollen, wenn man sich dafür entscheidet.

Sie könnten auch in boo suchen. Es ist eine statische CLI-Sprache, die wie Python aussieht, dank der Typinferenz. Der Compiler ist sehr erweiterbar und ich hatte einige Erfolge damit, ein paar kleine DSLs darauf zu schreiben. Sie könnten auch in Orens Buch Writing DSLs with boo schauen.

+0

Haben Sie irgendwelche Gedanken über die relative Leistung der beiden Ansätze? Oder zu den Problemen mit der AppDomain-Verwaltung, die mit der C# -Option auftreten? Oder die Schwierigkeit, einen DLR-Scripting-Host einzubetten? (Guter Punkt, ich habe es aufgezählt). – Dave

+0

"Aber es wird nie schneller sein ..." Wollen Sie sagen, dass die Strafe für die Cross-AppDomain Methodenaufrufe geringer ist als der DLR dynamische Versandmechanismus? Haben Sie dafür irgendwelche Quellen? (In der C# -Implementierung muss ich die kompilierten Assemblys entladen können, daher die AppDomain-Isolierung.) – Dave

+1

@Dave: Oh, da ist dieses Problem ... Diese Strafe wird gezahlt, wenn Sie die AppDomain überschreiten. Die geringen dynamischen Versandkosten kosten Sie überall im Script. Ich bin mir nicht sicher, wie sich das in Ihrem Anwendungsfall ausgleichen wird. –

Verwandte Themen