Uso de una DSL para generar el código de C#

Question

Actualmente, el proyecto con el que estoy trabajando no tiene modelos completamente fijos (debido a una influencia externa) y, por lo tanto, me gustaría tener cierta flexibilidad para escribirlos. Actualmente se replican en tres capas diferentes de la aplicación (db, web api y cliente) y cada una tiene una lógica similar (es decir, validación).

Me preguntaba si hay un enfoque que me permita escribir un archivo de modelo (por ejemplo, en ruby), y luego hacer que convierta ese modelo en los archivos C# necesarios. Actualmente parece que estoy escribiendo mucho código repetitivo que puede cambiar en cualquier etapa, mientras que este enfoque generado me permitiría enfocarme en cosas mucho más importantes.

¿Alguien tiene una recomendación para algo como esto, un dsl/idioma en el que puedo hacer esto, y alguien tiene alguna experiencia con respecto a algo como esto?

Answer 1

Esto se puede hacer fácilmente con ANTLR. Si el resultado es lo suficientemente similar, puede simplemente usar el mecanismo de plantillas de texto; de lo contrario, puede generar un árbol de sintaxis abstracta para que pueda recorrer.

Answer 2

He visto un sistema que usaba clases parciales y métodos parciales para permitir la regeneración de código sin afectar el código personalizado. El "motor de reglas" si se generó por completo a partir de un diagrama de estado de Visio. Esto es básicamente un flujo de trabajo pobre pero muy fácil de modificar. El diagrama de Viso se exportó a XML, que se leyó usando powershell y T4 para generar las clases.

El ejemplo anterior es de una DSL externa. ES DECIR. externo al lenguaje de programación en el que se ejecuta la aplicación. Por otro lado, podría crear una DSL interna que se implementa y usa en un lenguaje de programación.

Esto y el anterior article on DSLSs de Code-Magazine son bastante buenos.

En el enlace de arriba, Neal Ford le muestra cómo crear una DSL interna en C# utilizando una interfaz fluida.

Una cosa que no ha mencionado aún es que puede poner este atributo [EditorBrowsable (EditorBrowsableState.Never)] en sus métodos para que no parezcan intelisense. Esto significa que puede ocultar los métodos que no son DSL (si lo desea) en la clase del usuario de la DSL, haciendo que la API fluida sea mucho más reconocible.

Se puede ver una interfaz fluida siendo escrita en vivo en esta serie de videos por Daniel Cazzulino en la escritura de un contenedor IoC con TDD

Sobre el tema de los DSL externos también tienen la opción de Oslo (CTP at the moment) que es bastante potente en su capacidad para permitirle crear DSL externas que se pueden ejecutar directamente en lugar de utilizar la generación de código, lo que da la impresión de que no es realmente una DSL en absoluto.

Answer 3

Creo que está en el camino correcto.

Lo que suelo hacer en una situación como esta es diseñar un lenguaje simple que capture mis necesidades y escribir un analizador LL1 (Recursive Descent) para ello.

Si el lenguaje tiene que tener una sintaxis C# no trivial, puedo citar eso, o simplemente ajustarlo entre corchetes que puedo reconocer, y simplemente pasarlo al código de salida.

Puedo hacer que genere una estructura de árbol de análisis sintáctico y generar, por ejemplo, 3 tipos diferentes de código, o puedo generar código sobre la marcha, ya sea usando una variable de modo con 3 valores, o simplemente simultáneamente escribe el código en 3 archivos de salida diferentes.

Hay más de una forma de hacerlo. Si tiene miedo de escribir analizadores (como lo hacen algunos programadores), hay mucha ayuda en otros lugares en SO.