¿Tiene sentido integrar lenguajes de scripting a las aplicaciones C#?

Question

He estado pensando en integrar Ruby en mi aplicación, pero algunos de mis amigos en el trabajo me dijeron que C# ya es de muy alto nivel. Pero para mí parece que tiene más equipaje para hacer cosas muy rápidas.

¿Qué piensan?

Además, si me integro, ¿tiene sentido limitarlo para que pueda hacer casi cualquier cosa utilizando la funcionalidad existente de la aplicación, pero no extenderla?

Motivo para esto es que los lenguajes de escrutinio no son conocidos por su rendimiento, y si dices darles a las personas que escriban Filtros como Desenfocar, Contraste, etc., entonces serían mucho más lentos de lo que deberían y degradarían la experiencia del cliente del scripter, ¿verdad?

Answer 1

He integrado secuencias de comandos (lua) en las aplicaciones, y también he usado C# en sí mismo como un "lenguaje de scripting", compilando montajes dinámicos sobre la marcha del código proporcionado por el usuario. También implementé sistemas "plug-in" usando ensambles provistos por el usuario que se ajustan a interfaces o clases base específicas.

Hay muchas cosas que considerar, desde la seguridad, el rendimiento hasta la confusión del usuario final. No creo que pueda hacer una declaración general como "los lenguajes de scripting no pertenecen a las aplicaciones", o incluso "los lenguajes de script pertenecen a las aplicaciones". Cualquier caso específico dado necesita una consideración cuidadosa de todas las opciones y las consecuencias de esas opciones antes de correr y hacer algo de lo que pueda arrepentirse más adelante.

Answer 2

Puede haber un golpe de rendimiento para una característica determinada cuando se implementa a través de una interfaz de script en lugar de hacerlo de forma nativa a través de su aplicación, pero si desea permitir que los usuarios implementen su aplicación y les permite implementar una función que es útil para ellos que no es compatible de forma nativa en su aplicación, entonces me parece una buena idea. Si termina con un script de usuario particular que es muy popular, siempre puede lanzarlo como una característica nativa de su aplicación en una versión posterior si puede mejorar su rendimiento. ¡Espero que esto ayude!

Answer 3

Me gusta poder escribir scripts para extender la funcionalidad de una aplicación. Aún mejor cuando el lenguaje de scripting es muy conocido.

No limitaría la funcionalidad de un script en función de las preocupaciones sobre el rendimiento. No sabe cómo se comportará algo en el hardware futuro, por ejemplo; sin embargo, debe limitar lo que puede hacer por la seguridad/funcionalidad.

Si tiene problemas de rendimiento, implementaría los puntos de extensión a través de un script, pero también a través de complementos que permitirían ejecutar y ejecutar el código compilado.

Editar

En general no creo que se presenta a continuación, que se extienden más vulnerabilidades de una aplicación a través de un enchufe en, por ejemplo. En cuanto a las vulnerabilidades específicas, realmente no podría decir sin saber más acerca de su aplicación. Pero tome los navegadores web, por ejemplo. IE ha tenido una gran cantidad de fallas de seguridad porque las secuencias de comandos podrían acceder a más recursos de lo que deberían haber sido.

Forzar extensiones a través de código compilado le permite aprovechar los mecanismos para ayudar a prevenir ataques. Podría inspeccionar un ensamblaje, por ejemplo (Asumiendo .net aquí). buscando fácilmente un código malicioso (sí, puede hacer esto también con secuencias de comandos), o puede evitar el acceso a ciertos recursos de Code Access Security. También puede aprovechar la firma de código y solo cargar complementos de editores de confianza.

Answer 4

Dependiendo de lo que intente lograr, le puede interesar lo que PowerShell tiene para ofrecer. Puede hacer que su aplicación sea un host de scripting personalizado de PowerShell, o simplemente proporcionar cmdlets que manipulen la aplicación.

En cualquier caso, los usuarios se benefician de un lenguaje de scripting rico, potente y sensato con soporte integrado de .NET/COM/WMI, pero no tienen que ser desarrolladores para usarlo.

También está desarrollando una habilidad que sus usuarios ya podrían tener. Si aún no lo tienen, pueden aprenderlo para su aplicación y luego beneficiarse de él en el futuro.

Exchange Server 2007 implementa un servidor de scripts personalizado, si desea ver un ejemplo de cómo funciona.