Pregunta

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, API web 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 (digamos en ruby), y luego hacer que convierta ese modelo en los archivos de C # necesarios. Actualmente parece que solo estoy escribiendo una gran cantidad de código repetitivo que puede cambiar en cualquier etapa, mientras que este enfoque generado me permitiría concentrarme 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?

¿Fue útil?

Solución

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

Otros consejos

He visto un sistema que utilizaba clases parciales y métodos parciales para permitir la regeneración de código sin afectar el código personalizado. El & Quot; motor de reglas & Quot; si se generó completamente a partir de un diagrama de estado de Visio. Este 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 un DSL externo. ES DECIR. externo al lenguaje de programación en el que se ejecuta la aplicación. Por otro lado, podría crear un DSL interno que se implementa y utiliza en un lenguaje de programación.

Este y el anterior artículo sobre DSLS de Code-Magazine son bastante buenos .

En el enlace anterior, Neal Ford le muestra cómo crear un DSL interno en C # usando una interfaz fluida.

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

Puede ver una interfaz fluida escrita en vivo en esta serie de videos por Daniel Cazzulino en escribir un contenedor de IoC con TDD

Sobre el tema de DSL externos también tiene la opción de Oslo (CTP en este momento) que es bastante poderoso en su capacidad de permitirle crear DSL externos que se pueden ejecutar directamente en lugar de usar el código de generación que pensar que no es realmente un DSL en absoluto.

Creo que estás 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 (Descenso recursivo) para ello.

Si el lenguaje tiene que tener una sintaxis no trivial de C #, puedo citarlo o simplemente envolverlo entre paréntesis que pueda reconocer y simplemente pasarlo al código de salida.

Puedo hacer que genere una estructura de árbol de análisis y generar, digamos, 3 tipos diferentes de código a partir de eso, o simplemente puedo hacer que genere código sobre la marcha, ya sea usando una variable de modo con 3 valores, o simplemente escribiendo simultáneamente código para 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 sobre SO.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top