Pregunta

¿Qué tecnología recomendaría usted para crear un DSL para un Reglas de negocio y Validación Application Block para .NET ? Y por qué?

La arquitectura del marco se establece y sometidos a ensayo de-por una producción. Sólo quiero crear un procesador de .NET para transformar las reglas legible a una compilados implementaciones de reglas.

Las opciones que yo sepa son:

Por desgracia, ninguno de estos enfoques ofrece nada para construir IDE más o menos amigable para DSL edición, dada la sintaxis DSL (que evolucionaría).

Todas las ideas o sugerencias?

¿Fue útil?

Solución

siguiente generación de la plataforma de desarrollo de aplicaciones de Microsoft, con nombre código Oslo

  

Hace que sea más fácil para que la gente escribe cosas de manera que tengan sentido para el dominio del problema que están trabajando en

Oslo parece consistir en una herramienta de diseño visual denominado "Cuadrante", un lenguaje de modelado llamado "M", y el repositorio "Oslo" (una base de datos de SQL Server) que almacena las reglas.

Así que si leo las cosas correctamente, se podría definir un lenguaje de modelado en M, utilizar Cuadrante para definir y editar las reglas de validación usando su propio lenguaje de modelado, y escribir una aplicación que hace uso del repositorio de Oslo, la generación de reglas de negocio y Validación Application Block para .NET.

Otros consejos

Un lenguaje gráfico de reglas de negocio no es una buena idea. Yo evitaría que las reglas de negocio tienen un montón de si los controles y bucles en ellos, que no se visualizan bien.

Es mucho mejor con un lenguaje textual para la descripción de las reglas de negocio.

Para obtener una experiencia de usuario phenomenial para editar el código que necesita:

  1. Un analizador con buena recuperación de errores
  2. La capacidad de hacer incrementales recompilación

Buena recuperación de errores le permite determinar de manera efectiva la intención programador a partir de construcciones syntatically incompletos. Eso es crucial para implementar Intellisence.

La capacidad de hacer incremental recompilación le da la capacidad de hacer la compilación de fondo eficiente en respuesta a las modificaciones del usuario.

La forma más fácil de conseguir una buena recuperación de errores es escribir su analizador con la mano. De esa manera usted puede usar cualquier cantidad de mirar hacia adelante, o las reglas algrorithmic, para averiguar qué hacer en presencia de errores de sintaxis.

Cuando se utiliza un generador de filtros para crear su programa de análisis, de que pierda una gran flexibilidad en el trato con los errores de sintaxis. Esta flexibilidad hace que la diferencia entre una buena experiencia Intellisence y una crapy. Por lo tanto, recomiendo que acaba de escribir a mano usando descendente recursivo.

La implementación eficiente re-compilación requiere que usted será capaz de: 1) correctamente descomponer análisis semántico en fases (para algo así como C # esto sería: primera construcción de espacio de nombres y tipo símbolos, a continuación, resolver utilizando sentencias, a continuación, resolver clases de base, etc). 2) La capacidad de construir un gráfico de la dependencia de fase-consciente 3) Los algoritmos para el procesamiento de la gráfica de dependencia, y invalidar partes de ella en respuesta a ediciones de usuarios

Por idioma completamente flegged programación, la implementación de recompilación puede volver muy difícil. En su caso, debido a que está describiendo las reglas de negocio, que podría ser mucho simpiler para usted (o si la compilación es lo suficientemente rápido como es posible que ni siquiera lo necesita).

Por lo tanto, me gustaría empezar con el analizador, y luego construir Intellisence en la parte superior de la misma.

Si usted puede evitar la integración VS, lo haría. La integración en VS requiere una gran cantidad de plomería y la interoperabilidad es probable que cause dolores de cabeza. Hay algunas compañías que venden controles del editor de formularios de Windows que conectar su analizador hasta. Que son mucho más fáciles de integrar con que VS.

Otra alternativa interesante es posiblemente usar F # citas.

Citas permitirá tratar parte del programa como los datos, para que pueda obtener la AST, analizarla y traducirla a otro idioma o ejecutar de algún modo no estándar. Junto con la flexibilidad de F #, usted debe ser capaz de expresar muchas cosas, por lo que habría que desarrollar una biblioteca interna F # DSL / combinador para la descripción de las reglas y un traductor / intérprete para F # citas para ejecutarlas.

No estoy seguro como una regla Bussines podría ser similar, pero se podría escribir algo como esto:

let rule = <@
  if (exists customer having validEmail) then success
  else require whatever 
@>

escribí una introducción a este tema en mi blog. Desafortunadamente, no ha habido grandes cambios en el F # CTP y que aún no han actualizado el código fuente, pero deben darle una buena idea de cuáles son las posibilidades y limitaciones de este enfoque.

Un buen ejemplo de DSL es F framewrok pruebas # unidad:

[EDIT] Solo para aclarar por qué creo que esto puede ser un buen método:

  • Si utiliza Visual Studio para los editting DSL (y se puede utilizar la versión de Shell con F # instalada de forma gratuita), obtendrá una muy buena experiencia de edición de forma gratuita. No sólo el resaltado de sintaxis, sino también INTELLISENSE que va a sugerir las posibles construcciones y también un tipo fondo de comprobación que sirve como corrector 'gramática' de la DSL.
  • En comparación con otros enfoques éste es quizás uno de los más fáciles de implementar.
  • La única limitación es que está limitada por la sintaxis # F. Sin embargo, el diseño de su propio idioma es muy difícil, por lo que esto puede no ser tan malo en absoluto. Especialmente teniendo en cuenta la flexibilidad de F #.

[/ EDIT]

Espero que esto ayude!

que haría uso de Boo, creo que es actualmente una de las herramientas más flexibles para la creación de DSL. Hay una libro muy bueno sobre el tema. de Ayende y blogs de Rodrigo son buena fuente de inspiración también.

Sobre el IDE, que podría extenderse SharpDevelop , echar un vistazo a este .

La herramienta estándar para la construcción de las costuras de DSL para ser antlr - es un generador de analizador léxico / analizador de gran alcance con una gran cantidad de idiomas de destino para la salida del compilador. Tiene backends para C #, Java, C / C ++, Python etc. (véase la objetivos de generación de código lista) y le permite inyectar código personalizado en su compilador en su idioma de destino con facilidad.

También hay un muy potente IDE (ANTLRWorks) y gran cantidad de documentación. (Salida El Defenitive antlr Referencia de Terrence Parr, la autor de antlr) Para referencias sobre quien lo usa ver la página Testimonlals .

Usted todavía tiene que hacer la mayor parte de la instalación de cañerías para el IDE a sí mismo, pero debe ser mucho más fácil dado el marco compilador robusto que se obtiene de antlr. Este debería ser el caso para la mayoría de las soluciones publicadas aquí ...

Actualmente estoy usando un compilador escrito con antlr preprocesasen nuestro propio DSL a la salida C / C ++ y estoy muy contento con él. Basta ya de la publicidad, usted debe probarlo por ti mismo :) divertirse!

Meta Programación del sistema

  

Se pueden definir los editores de idioma personalizadas y otras limitaciones para cualquier nuevo idioma, por lo que el trabajo con esos DSL vuelve muy simple. expertos en los sectores que no están familiarizados con la programación tradicional pueden trabajar fácilmente en MPS con sus lenguajes específicos de dominio utilizando la terminología específica del dominio.

Soy nuevo en ella, pero Ometa parece como un ideal herramienta para el desarrollo de DSL. No parece ser un IDE alrededor de ella, pero la buena noticia es que las "reglas" se puede escribir en Ometa son muy legible. (Y se trata de izquierda recursividad, que es muy fresco.)

En este momento hay implementaciones Ometa en al menos Javascript (muy emocionante para mí) y Python, tal vez otros. En cuanto a C #, Jeff Moser está trabajando en uno, lo que se puede leer acerca de su blog y ver más en CodePlex . Buena suerte.

Boo + Ometa = Boo.OMeta.Parser

En la actualidad el analizador está en desarrollo pero ya se puede utilizar para la creación de DSL externos complejos. Ometa es poderosa herramienta que permite a los programadores implementar fácilmente analizadores léxicos y analizadores. compilador extensible arquitectura de canalización de Boo permite sustituir Boo.Parser estándar con Boo.OMeta.Parser. Se puede utilizar para extender la sintaxis Boo con casi cualquier tipo de sintaxis. El ejemplo se puede encontrar aquí .

meta # está tratando de resolver este problema.

Si desea crear un amistoso IDE que edita los DSL, hacer que el IDE totalmente gráfica, y compilar a .NET objetos (o usar algo como IronPython como lengua de cola).

Si las reglas son bastante simples, se puede poner en práctica toda la estructura de reglas de forma gráfica. Si las reglas son lo suficientemente compleja, "legibilidad" se convierte en una meta imposible.

De cualquier manera, si un conjunto de clases de .NET u objetos IronPython que crean el código intermediario no es "legible" suficiente, entonces lo más probable es, usted quiere algo más ficticia a prueba de una gramática.

Dicho esto, si lo que desea es crear un lenguaje sencillo que los programadores pueden utilizar para crear reglas de negocio, no dude en utilizar cualquiera de los anteriores, y hacer la sintaxis suficiente como para no minimalista a necesitar IDE de Visual Studio.

Ruby es un gran lenguaje para la creación de DSL. Por ejemplo Rake DSL es un script de compilación escrita con Ruby.

Con la próxima rel="nofollow IronRuby es posible escribir scripts que llaman a su código C # directamente.

Aquí es href="http://obiefernandez.com/presentations/obie_fernandez-agile_dsl_development_in_ruby.pdf" rel="nofollow noreferrer"> artículos en la escritura DSL en Ruby.

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