2009-11-20 7 views
5

Estoy considerando incorporar un lenguaje de scripting en uno de mis proyectos de software y he identificado dos opciones: compilar C# en tiempo de ejecución mediante CodeDOM e incorporar un lenguaje de scripting basado en DLR. Ambas opciones me darían acceso completo al .NET Framework.Razones para utilizar un lenguaje basado en DLR en lugar de C# para las tareas de scripting?

La operación en la que me gustaría crear secuencias de comandos sería una transformación definida por el usuario de un DataRow y un conjunto de metadatos que da como resultado un DataRow modificado. Espero que estas transformaciones sean composable y se invoquen con frecuencia. Por supuesto, espero que el usuario final proporcione y modifique las transformaciones.

Con esta carga de trabajo en mente, ¿hay alguna ventaja clara al usar un enfoque sobre otro?

Respuesta

3

Para los usuarios, generalmente es mejor usar lenguajes con una sintaxis más indulgente, por razones obvias. Entonces, recomendaría usar un lenguaje basado en DLR. Si tiene tiempo y recursos, una DSL especializada es la mejor opción, porque puede ofrecer una sintaxis pequeña y fácil de aprender, y es más fácil evitar que el usuario haga cosas que no deberían hacer (como acceder al sistema de archivos). , por ejemplo ...)

No puedo hablar por experiencia, pero, por lo que he visto, el DLR puede ser bastante rápido (IronPython lo hace mejor que Python nativo). Pero el envío dinámico siempre implica una ligera sobrecarga. En la mano, las llamadas entre dominios de aplicación cruzada son bastante caras. Si bien el costo de envío dinámico se paga en todas partes dentro de la secuencia de comandos, el costo del dominio de aplicación cruzada solo se paga una vez por llamada de secuencia de comandos. Cuál mejor depende de cuánto harán tus scripts.

Incrustar un servidor de secuencias de comandos DLR es not difficult at all. Lo que es difícil es rodar su propia DSL, si elige ir por ese camino.

También puede consultar boo. Es un lenguaje CLI estático que se parece a Python, gracias a la inferencia de tipo. Su compilador es altamente extensible, y he tenido cierto éxito al escribir algunas pequeñas DSL en él. También puede consultar el libro de Oren Writing DSLs with boo.

+0

¿Tiene alguna idea sobre el rendimiento relativo de los dos enfoques? ¿O sobre los problemas de administración de AppDomain que surgen con la opción C#? ¿O sobre la dificultad de incrustar un host de scripting DLR? (Buen punto, lo hice upvote). – Dave

+0

"Pero nunca será más rápido ..." ¿Está diciendo que la penalización por las llamadas al método de AppDomain será menor que el mecanismo de envío dinámico DLR? ¿Tienes alguna fuente para eso? (En la implementación de C#, necesitaré poder descargar los ensamblados compilados, de ahí el aislamiento AppDomain.) – Dave

+1

@Dave: Ah, ese es el problema ... Esa penalización se paga cuando cruzas el Dominio de la aplicación. El ligero costo de envío dinámico lo paga en todas partes dentro del script. No estoy seguro de cómo se equilibrarán en su caso de uso. –

Cuestiones relacionadas